How to svg <text> element vs path outlines: a practical comparison
- Step 1Classify the SVG: content or identity — Content SVGs (charts, diagrams, infographics) carry words a reader needs to select, search, or translate — keep those as
<text>. Identity SVGs (logos, wordmarks, badges) carry a fixed letterform that must never change — those are conversion candidates. - Step 2Check whether the font will always be available — If the SVG is served from a site that also serves the font via
@font-face, live<text>renders correctly. If the SVG travels as a standalone file — emailed, embedded in a PDF, dropped into a design handoff — the viewer may lack the font, so outline it. - Step 3Measure the live-text baseline — Note the current
<text>file size. A short wordmark is often around 100-300 bytes. This is your floor; outlining will increase it, and you want to know by how much before committing. - Step 4Convert the identity SVGs — For each SVG you decided to freeze, supply its font as a public TTF/OTF/WOFF URL and run the converter. Each
<text>becomes a<path>with the samefilland anaria-label. - Step 5Compare before and after — Record the outlined file size against the live-text baseline, then gzip both — gzip recovers much of the path-data overhead, so the transfer-size gap is smaller than the raw-byte gap suggests.
- Step 6Keep the live version in source control — Outlining is one-way: once a
<text>is a<path>, you cannot re-flow the words. Keep the original<text>SVG in your repo so future edits start from editable text, and re-outline on export. If the outlined logo will also become a favicon, feed it to the favicon generator afterward.
Live <text> vs outlined <path>
Field-by-field trade-offs. "This tool" notes what JAD's converter specifically does for the outlined side.
| Property | Live <text> | Outlined <path> (this tool) |
|---|---|---|
| File size | Smallest — a short wordmark is ~100 bytes | Larger — often several KB of path data per line |
| Font dependency | Needs the font resolvable at view time | None — shapes are baked in |
| Rendering consistency | Varies with installed/served fonts | Identical everywhere |
| Native text selection | Yes | No (it is geometry) |
| Search / translate | Yes | No native text; aria-label carries the string |
| Screen-reader access | Yes, with proper markup | Via the aria-label written on each <path> |
| Reshaping letterforms | No (it is text) | Yes — edit nodes in a vector editor |
| Reflowing the words | Yes | No — outlining is one-way |
Which side to choose
A quick mapping from use case to the right form.
| Use case | Recommended form | Why |
|---|---|---|
| Logo / wordmark | Outlined path | Letterform must be exact and font-free |
| Chart / axis labels | Live <text> | Readers select/copy values; smaller files |
| Standalone SVG emailed/handed off | Outlined path | Viewer may not have the font |
SVG served with its own @font-face | Live <text> | Font is guaranteed; keep it small |
| Badge baked into many product images | Outlined path | Consistent across every render target |
| Translatable UI copy | Live <text> | Words must stay editable per locale |
Cookbook
Worked decisions for common SVGs, showing which form wins and what the converter does when you outline.
Logo wordmark: outline it
A header logo must look identical on every device and must not depend on the brand font being installed. Outlining freezes it; the aria-label keeps the brand name readable to crawlers.
Live (risky on machines without the font):
<text font-family="BrandSans" x="0" y="40"
font-size="40" fill="#111">ACME</text>
Outlined (font-free, still labelled):
<path d="M0 8 L..." fill="#111" aria-label="ACME"/>
Decision: OUTLINE. Identity asset, must be exact.Chart axis labels: keep live
A data chart's tick labels should stay selectable and searchable, and the page already serves the font. Outlining would bloat the file and kill selection for no benefit.
Keep as: <text x="30" y="190" font-size="11">0</text> <text x="90" y="190" font-size="11">25</text> <text x="150" y="190" font-size="11">50</text> Decision: KEEP LIVE. Content SVG, font is served, readers copy the numbers.
Email signature SVG: outline it
Email clients strip @font-face and external font links. A signature with live <text> falls back to a default font in most clients; outlining is the only reliable way to preserve the look.
Problem: <text font-family="Calibri">Jane Doe</text>
renders in a fallback font in most mail clients.
Fix: outline with the Calibri WOFF/TTF URL ->
<path d="..." aria-label="Jane Doe"/>
Decision: OUTLINE. Standalone, font cannot be relied on.Size impact of outlining
Outlining trades bytes for independence. The raw increase looks large, but gzip narrows the transfer gap. For a once-cached logo this is a non-issue.
Wordmark 'ACME', 40px: Live <text>: ~120 bytes Outlined paths: ~6-12 KB raw Outlined, gzip: ~2-4 KB transfer Rule: fine for logos (loaded once, cached); avoid for paragraphs of body text.
Hybrid: outline visually, label semantically
You can have both visual independence and machine-readable text. The converter already does this — the visible shape is a path, the aria-label is the string.
Output the tool produces:
<svg role="img" aria-label="ACME — Quality Tools">
<path d="..." aria-label="ACME"/>
<path d="..." aria-label="Quality Tools"/>
</svg>
→ Crawlers read the labels; pixels are font-free.Edge cases and what actually happens
Outlining body copy
AvoidConverting paragraphs of running text to paths bloats the file, removes selection, and breaks translation. Keep body text live; only outline identity assets. There is no benefit to outlining text the page already serves a font for.
Expecting paths to stay editable as words
By designOnce converted, the words are geometry — you cannot re-type or re-flow them. Keep the live-<text> source so future edits start from editable text and you re-outline on export.
Assuming aria-label equals full text accessibility
PartialThe converter labels each <path> with its original string, which screen readers can announce, but outlined text is not selectable and won't be found by in-page text search. For content that must be selectable, keep it live.
Centered text drifting after conversion
By designThe converter ignores text-anchor and lays glyphs from x. Centered live <text> will start at x once outlined. Decide x as the left edge before converting if alignment matters.
Live <text> that relies on CSS font-size
PartialThe converter reads the font-size attribute, defaulting to 16 if absent. If your live <text> got its size from a stylesheet, outline it after writing the size onto the element, or the path will be 16px.
Color font in the live text
UnsupportedA live <text> rendered with a color/emoji font cannot be outlined into single-color paths here. Keep it live (and accept font dependency) or rasterize that portion as an image.
SVG already exported as paths
ExpectedIf a design tool already converted text to paths, there are no <text> elements and the converter errors. That is the end state you wanted — the SVG is already font-independent.
Gzip already in play
PreservedIf your server gzips SVG responses, the raw-byte increase from outlining overstates the real cost. Compare gzipped sizes when judging the trade — the transfer gap is usually a few KB, not tens.
Frequently asked questions
Is live <text> or outlined path smaller?
Live <text> is far smaller — a short wordmark can be ~100 bytes versus several KB of path data. For size-sensitive content SVGs served with their own font, keep <text>.
Can screen readers read SVG text either way?
Live <text> is readable with proper markup. Outlined paths are not native text, but JAD's converter writes an aria-label of the original string onto each <path> so the words are still announced.
When should I outline instead of using <text>?
Outline identity assets — logos, wordmarks, badges — and any SVG that travels as a standalone file where the font may be missing. Keep content text live.
Does outlining preserve kerning?
Yes. Outlines come from the font's own glyph paths and advance widths via getPath, so spacing matches the font. CSS letter-spacing, however, is not applied.
Will outlined text look identical across browsers?
Yes — that is the main reason to outline. The shapes are baked in, so there is no font resolution and no fallback substitution at view time.
Can I still translate outlined text?
No. Outlining freezes the glyphs of one language. Keep translatable copy as live <text> and outline only fixed identity strings.
Does the converter keep my fill colors?
Yes. Each <path> keeps the original <text>'s fill, or currentColor if none was set, so CSS theming keeps working.
Is outlining reversible?
No. Paths cannot be turned back into editable words. Keep the live-<text> source under version control.
How does each form behave in a PDF?
Outlined paths render identically in any PDF because they need no font. Live <text> depends on the PDF renderer embedding or substituting the font, which is unreliable on servers without it.
What about emoji or color fonts in my text?
Those can't be outlined to single-color paths here. Keep them live or rasterize them as images.
Does the tool let me pick a font from a list?
No. You supply the exact font as a public TTF/OTF/WOFF URL; the converter traces shapes from that file. This guarantees the outline matches your design's font.
Why keep both a text and a path version?
Source control keeps the editable <text> for future changes; the exported outlined version is what you ship. Re-outline whenever the text changes. Once outlined, a single-colour wordmark also feeds cleanly into the monochrome converter if you need one-colour variants.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.