How to convert text to svg paths online free
- Step 1Make sure your text lives in <text> elements — This tool outlines
<text>only. Open your file and confirm the words you want frozen are real<text>nodes (withx,y,font-size, and ideallyfill). If your design tool exported the text already as paths, there is nothing to convert. If there are no<text>elements at all, the tool stops with an error rather than guessing. - Step 2Host the font at a public URL — Pick the TTF, OTF, or WOFF file for the exact face used in your SVG and put it somewhere fetchable over HTTPS — your own CDN, a GitHub raw URL, or Google Fonts'
fonts.gstatic.com. The URL must allow cross-origin fetch (CORS) and return a 2xx response. WOFF2 is not accepted by the parser, so convert it to WOFF/TTF first if that is all you have. - Step 3Load the SVG into the tool — Drop or paste your SVG above. It is parsed locally with
DOMParser; nothing about the SVG is sent anywhere. The tool finds every<text>element in the document, including any nested in groups. - Step 4Paste the font URL — Enter the public font URL in the Font URL field. This is the only option the tool exposes — there are no size, weight, spacing, or merge controls, because all of that is read from each
<text>element's own attributes (font-size) and the font's built-in metrics. - Step 5Run the conversion — The browser fetches the font, parses it with
opentype.js, and for each non-empty<text>callsgetPath(content, x, y, fontSize), replacing the element with a<path>carrying the tracedd, the originalfill, and anaria-label. The metrics panel reports how many text nodes were outlined and the font family name read from the file. - Step 6Download, shrink, and verify in a clean environment — Save the
*-outlined.svgand open it on a machine that does NOT have the font installed (or in a private browser window). The letters must look right. Path data is verbose, so run the result through the SVG minifier before shipping, and the metadata scrubber if the source carried editor cruft. Check that any centered or right-aligned text is positioned where you expect — see the edge cases ontext-anchorbelow if it drifted left.
What the tool reads from each <text> element
For every <text> node the converter pulls exactly these attributes and nothing else. Anything not listed here is ignored during outlining.
| Source attribute | Default if absent | How it is used |
|---|---|---|
x | 0 | Left start position passed to getPath — text is laid out rightward from here |
y | 0 | Baseline Y passed to getPath |
font-size | 16 | Em size in user units for the traced glyphs |
fill | currentColor | Copied verbatim onto the generated <path> |
| text content | (skipped if empty/whitespace) | Outlined glyph-by-glyph from the supplied font |
font-family | (ignored) | Not used — the font comes from your URL, not this attribute |
Input / output contract
The exact shape of what goes in and what comes out, taken from the implementation.
| Aspect | Behaviour |
|---|---|
| Required SVG input | An SVG document containing at least one <text> element |
| Required option | fontUrl — a public, CORS-fetchable TTF/OTF/WOFF URL |
| Font formats accepted | TTF, OTF, WOFF (WOFF2 is rejected by the parser) |
| Per-element output | One <path> with d (3-decimal precision), fill, and aria-label |
| No-text input | Stops with the error "No <text> elements found to outline." |
| Output filename | <original-stem>-outlined.svg |
| Reported metrics | "Text nodes outlined" count and the font family name |
Cookbook
Real before/after XML for the common conversion cases. Coordinates are simplified for readability; actual path data is far longer.
A two-line label becomes two paths
The canonical case: an SVG with <text> nodes for a wordmark. Each <text> turns into its own <path>, keeping the per-element fill and gaining an aria-label. The font-family attribute on the source is irrelevant — the shapes come from your font URL.
Input: <svg viewBox="0 0 400 120"> <text x="20" y="50" font-size="36" fill="#0f172a">Hello, world.</text> <text x="20" y="100" font-size="18" fill="#475569">tagline here</text> </svg> Option: fontUrl = https://example.com/Inter-Regular.woff Output (filename: <name>-outlined.svg): <svg viewBox="0 0 400 120"> <path d="M21.4 22.0 L..." fill="#0f172a" aria-label="Hello, world."/> <path d="M21.0 78.3 L..." fill="#475569" aria-label="tagline here"/> </svg> Metrics: Text nodes outlined: 2 | Font: Inter
Missing fill defaults to currentColor
When a <text> has no fill, the generated <path> is given fill="currentColor", so it inherits the surrounding CSS color. This keeps icon-style SVGs themeable after outlining.
Input: <svg viewBox="0 0 200 40"> <text x="0" y="30" font-size="24">MENU</text> </svg> Output: <svg viewBox="0 0 200 40"> <path d="M0 8 L..." fill="currentColor" aria-label="MENU"/> </svg> → Set color:#e11d48 on a parent and the outlined word follows.
No font-size means 16
The tool defaults font-size to 16 and x/y to 0 when absent. If your <text> relied on a CSS stylesheet for size, the outlined path will use 16 instead — set the attribute explicitly before converting.
Input (size only in external CSS — not on the element): <svg viewBox="0 0 300 60"> <text x="10" y="40">Big Title</text> </svg> Result: outlined at font-size 16, baseline y=40. Fix: put the size on the element first -> <text x="10" y="40" font-size="40">Big Title</text>
Empty text node is left as-is
A <text> whose content is empty or only whitespace is skipped — it is not turned into a path and not removed. Only the metrics count drops.
Input: <svg viewBox="0 0 100 30"> <text x="5" y="20" font-size="16">OK</text> <text x="5" y="28" font-size="16"> </text> </svg> Output: <svg viewBox="0 0 100 30"> <path d="..." fill="currentColor" aria-label="OK"/> <text x="5" y="28" font-size="16"> </text> </svg> Metrics: Text nodes outlined: 1
Verify font-independence after export
The whole point is rendering without the font installed. After conversion, the SVG no longer needs the font at all — drop it on a fresh machine to prove it.
Before (needs Inter on the viewer's system): <text font-family="Inter" ...>Brand</text> After (needs nothing): <path d="..." aria-label="Brand"/> Test: open the outlined SVG in an incognito window on a phone that has never had Inter -> letters look correct.
Edge cases and what actually happens
SVG has no <text> elements
ErrorIf the document contains zero <text> nodes, the tool throws "No <text> elements found to outline." rather than silently returning the file. If your text was already exported as paths by a design tool, there is nothing to convert — that is the desired end state.
Font URL is missing or blank
ErrorWith no fontUrl, the tool stops with "Font-to-path requires a font URL. Provide a publicly-fetchable .ttf, .otf, or .woff font file." There is no built-in font library — you must supply the file location yourself.
Font URL returns 404 or is unreachable
fetch failedA non-2xx response throws "Could not fetch font (<status> <statusText>)." Test the URL in a browser tab first. If it downloads when typed directly but fails here, the cause is almost always CORS — see the next case.
Font host blocks cross-origin fetch (CORS)
blockedThe font is fetched from your browser, so the host must send Access-Control-Allow-Origin. Many private CDNs and some font services do not. fonts.gstatic.com (Google Fonts) and GitHub raw URLs generally work. Re-host the file on a CORS-enabled origin if the fetch is blocked.
WOFF2 file supplied
invalidThe parser supports TTF, OTF, and WOFF only. A WOFF2 URL fails to parse even though Google Fonts serves WOFF2 by default. Use the WOFF or TTF variant of the same face, or convert WOFF2 to WOFF before pointing the tool at it.
text-anchor=middle or end
By designThe converter reads only x/y/font-size/fill and lays glyphs out rightward from x. It does not honour text-anchor, so centered or right-aligned text shifts to start at x. Compute the left-edge x yourself before converting, or accept the left-aligned result and reposition the <path> afterward.
Multi-line text via <tspan> with dx/dy
PartialThe tool uses the <text> element's own x/y and its full textContent. Per-tspan x/y/dx/dy offsets are not applied, so a multi-line <text> built from positioned <tspan>s collapses onto one baseline. Split such text into separate <text> elements (one per line, each with its own y) before converting.
Arabic, Hebrew or other complex scripts
PartialGlyphs are outlined in logical order using the font's basic metrics; full bidirectional reordering and Arabic contextual joining are not performed. Latin, numerals, and simple scripts outline faithfully. For shaped RTL text, shape it in your design tool first and export those glyphs as paths there.
Character not present in the font
PreservedA glyph the font does not contain falls back to the font's .notdef glyph (typically an empty box), exactly as a browser would render it. Confirm your font covers every character in the SVG before converting.
letter-spacing / word-spacing in CSS
By designSpacing comes from the font's own advance widths and kerning via getPath; CSS letter-spacing/word-spacing on the <text> are not applied. If exact spacing matters, bake it into the design as separate positioned <text> elements first.
Frequently asked questions
Do I type my text into the tool?
No. The text comes from the <text> elements already inside the SVG you load. The tool reads each <text>'s content and outlines it — there is no text-entry box and no font picker, only a Font URL field.
Where does the font come from?
From a public URL you provide. The browser fetches that TTF/OTF/WOFF file and traces glyph outlines from it with opentype.js. There is no bundled font library.
Does it support WOFF2?
No. The parser accepts TTF, OTF, and WOFF. WOFF2 fails to parse, so use the WOFF or TTF version of the same font, or convert it first.
Will the outlined text match the original font exactly?
Yes, when you point the tool at the same font file used in the design. Outlines are the font's own glyph paths. The only thing lost is hinting, which only affects tiny pixel sizes.
What fill does the path get?
Whatever fill was on the <text>. If the <text> had no fill, the path gets fill="currentColor", so it inherits the surrounding CSS color.
Is the text still accessible after conversion?
Each generated <path> carries an aria-label equal to the original text, so screen readers and crawlers can still read the words even though the shape is now a path.
Does it handle centered (text-anchor=middle) text?
No. It lays glyphs out from the element's x and ignores text-anchor, so centered or right-aligned text starts at x. Adjust x to the left edge, or reposition the resulting path.
What about multi-line text using tspan?
Per-tspan offsets are not applied — the tool uses the parent <text>'s single x/y and full content. Split each line into its own <text> with its own y before converting.
Can it convert color or emoji fonts?
No. It traces single-color outline glyphs. Color fonts (COLR/CPAL, SVG-in-OpenType, Apple Color Emoji) are outside what opentype.js outlines here — rasterize those as images instead.
Is my SVG uploaded anywhere?
No. The SVG is parsed and rewritten locally in your browser with DOMParser/XMLSerializer. Only the font URL is fetched over the network.
What if my SVG has no text elements?
The tool errors with "No <text> elements found to outline." That usually means the text was already exported as paths — in which case it is already font-independent.
Which tier do I need?
Font-to-path is a Developer-tier tool in JAD. The SVG family file limit on Developer is 2 GB, far beyond any realistic text-bearing SVG. Once outlined, the SVG is just paths, so it works in any downstream SVG tool — for example the JSX converter to turn the font-free logo into a React component.
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.