An SVG font is a typeface written as XML, and browsers stopped drawing them.
Glyph outlines sit in an XML <font> element as plain text, so nothing is compressed: in FileFormer's own font test the SVG version came out at 159% of the source file, the only format in the set that finished larger than it started. Chrome dropped support at version 38 and Firefox never shipped it; only old iOS Safari ever drew them. If you have one, convert it to WOFF2 and keep the SVG as an archive copy.
A JPG or PNG stores the colour of every dot. An SVG stores instructions instead: a circle here, a curve there, this colour. Because it's text, you can read it, edit it, and draw it at any size without it going blurry. Change the code below and the picture follows.
Blow both up 8× and the difference is obvious.
The original badge, drawn once as SVG and once as a 64-pixel PNG. At the size it was made, they look identical. Enlarge them and the PNG runs out of dots, while the SVG is recalculated sharp at every size.
Readable as text. Useless as a web font.
An SVG's size depends on how many shapes it has, not how big it's shown. A simple icon is a few hundred bytes; a photo traced into shapes becomes megabytes of code that still looks worse than a JPG.
Because the outlines are text, an SVG font is bigger than the original.
SVG files can contain scripts and links to other files. That's why many sites refuse SVG uploads, and why email apps strip them out. We check for these parts in the SVGs you convert. The code at the top of the page is scanned live.
Open any SVG and see what it draws, what it carries and what it could run.
This page parses the file with your browser’s XML parser and walks every element. It finds scripts, event handlers, external loads and entity tricks, and sorts every byte by purpose. It also checks the size, viewBox and references, then runs a step-by-step optimiser and compares the result pixel by pixel. The file is only ever shown as an image, so nothing in it can run here. Everything happens on your device. .svgz files are decompressed first.
A typeface spelled out in tags, and why that made it obsolete.
Every other font format on this site is binary. TrueType and OpenType pack glyph outlines into tables addressed by byte offset; WOFF and WOFF2 wrap those same tables in compression. An SVG font does none of that. It is an XML document with a <font> element, a <font-face> child carrying the metrics, and one <glyph> element per character, each holding its outline in the same d path syntax an SVG drawing uses. You can open one in a text editor and read it.
That readability is the whole problem. Coordinates written as decimal digits take several bytes each where a binary table spends two, and XML adds a tag around every one of them. There is no internal compression, because the format has none to offer: its media type is image/svg+xml and its compression field reads "none (text)". When FileFormer converted one test typeface into every format it writes, the SVG version finished at 111.7 KB, or 159% of the source. It was the only format in the set that came out larger than it started.
Browsers agreed with that verdict. Chrome removed SVG font rendering in version 38, Firefox never shipped it at all, and only older iOS Safari builds ever drew them. A @font-face rule pointing at an SVG font today resolves to nothing, and the browser falls through to the next source in the list or to a system font. This is why the converter on this page will write an SVG font but refuses to read one back: there is no rendering engine left to preview it with, and rebuilding outlines from it would be guesswork rather than a round trip.
Two reasons remain to produce one. The first is a legacy requirement, an old Safari target or a build pipeline that still expects the format in its font stack. The second is an SVG workflow where a drawing tool reads glyph outlines out of the font rather than rendering text with it, which is a use the format is genuinely good at because the outlines are sitting there in plain path data. Both are narrow, and neither is a reason to ship one to a browser.
If you have inherited an SVG font and need it to work, convert it to WOFF2 and keep the SVG as an archive copy. WOFF2 is the format every current browser reads, and on the same test typeface it was the smallest output of all. Note that subsetting, the single biggest saving available on a web font, is skipped when the target is SVG: there is no point trimming glyphs out of a file the browser will not open. Pick WOFF2 first, then trim it to the characters your page actually uses.
SVG at a glance: the technical reference.
How to identify, serve and validate an SVG file, drawn from the W3C specification.
Every shape is a path, and a path is ten letters.
Inside the d attribute, each letter is a pen instruction followed by numbers. Capitals use absolute coordinates; lowercase ones move relative to the current point. Pick a command to see it drawn.
<path d="M 15 75 C 30 10, 70 10, 85 75"/>
From a W3C draft to every browser: the SVG timeline.
SVG was standardised early but took a decade to be usable everywhere, because Internet Explorer didn’t support it until version 9.
In and out of SVG.
Going to pixels is easy. Coming back from pixels means tracing, which works best on simple artwork.