Cookies for analytics and advertising
We use cookies for analytics and advertising, both sent to Google. Refusing changes nothing you can see.Read the privacy page
Converting HEIF to SVG traces the picture into vector paths rather than re-encoding it, so it redraws a photographed logo or sign as shapes that scale to any size. On an actual photograph it produces a posterised file several times larger than the original, and the page says so before you spend the time.
Up to 100 files at once. Mixed formats are fine.
They convert one after another and download together as a ZIP.
HEIF to SVG
Every other pair on this site takes a picture apart and puts the same picture back together in a different format. This one does not. A HEIF holds a grid of coloured pixels and an SVG holds shapes, and there are no shapes in the source — they have to be guessed at by finding boundaries between areas of similar colour and drawing an outline around each region.
That guess is what tracing is, and it is why the output is not the input in any sense. It also explains the whole shape of this page: whether the conversion succeeds depends almost entirely on whether your picture contains the flat regions the algorithm is looking for.
Four real files, tested first rather than afterwards. A flat logo round-tripped faithfully: 6 KB of source became 16 KB of SVG, with sharp edges, correct colours and rounded corners intact — and it now scales to a billboard, which is the case the feature exists for. A gradient banded, because a gradient is precisely the absence of flat regions.
The other two are the warning. A screenshot containing text produced an SVG forty times the size of the source, because every antialiased letter becomes its own little pile of paths. A photograph came out four times larger and posterised. Those are the numbers to weigh your own file against.
The good case is a photograph of something flat: a shop sign, a logo on a letterhead, a stencil, a stamp, an engraved plate, a drawing on paper. Those subjects genuinely are made of areas of one colour, so tracing finds real boundaries and the result is close to what a designer would have drawn.
The bad case is a scene. People, landscapes, product shots under studio lighting, anything with shadow gradation — those have no flat regions at all, so the tracer invents them by quantising the picture first. What comes back is a posterised copy in a format that is worse at holding photographs than any of the alternatives.
Because the algorithm looks for boundaries, everything that blurs a boundary hurts. Shoot straight on rather than at an angle, so a circular mark stays circular. Get even light across the whole subject: a shadow falling across half a sign becomes a colour boundary and the tracer will faithfully draw around it.
Avoid reflections and texture. A logo photographed on glossy card picks up highlights that become their own shapes, and paper grain under raking light turns into thousands of specks. Diffuse light, flat subject, camera parallel to it — the same discipline as photographing a document, for the same reason.
You choose how many flat colours the drawing is reduced to: four, eight, sixteen or thirty-two, defaulting to eight. Four is right for a single-colour mark, a stencil or a signature, and it produces the cleanest paths of any setting. Eight suits a flat illustration with a few tones.
Sixteen and thirty-two are for artwork with genuine shading, and they cost quickly — each additional colour is another set of regions with another set of outlines around them, so the file grows and the shapes multiply. On a photographed subject a high colour count mostly turns noise into paths.
The detail setting controls how tightly the paths follow the pixel edges and how small a shape has to be before it is discarded. Smooth accepts the loosest fit and throws away anything under sixteen pixels; balanced sits in the middle at eight; sharp follows closely and keeps shapes down to two pixels.
Smooth is usually the right answer for a photographed subject, because the edges in your picture are soft to begin with and the small shapes being discarded are camera noise rather than artwork. Sharp is for a clean source where every detail is deliberate — it will reproduce a ragged edge exactly as ragged as it was.
A common trick to reduce speck count is to blur the image slightly before tracing. It works, and it is not done here, because it works by softening exactly the sharp edges that are the only reason to trace a logo in the first place.
If your source needs that treatment, the tracer is telling you something about the source. A cleaner photograph, a flatter light or a lower colour count all address the cause. Blurring addresses the symptom and takes the crispness of the result with it.
Pictures larger than 1,600 pixels on the longest edge are scaled down before tracing. Tracing cost grows with the number of edges rather than the file size, and a twelve-megapixel photograph has an edge almost everywhere — left alone it can produce a multi-megabyte SVG over tens of seconds, which is a worse outcome than the one you came here to avoid.
Unlike a raster conversion, this scaling is not a loss of fidelity. The output is resolution-independent, so a logo traced at 1,600 pixels and the same logo traced at 4,000 render identically at any size. All that changes is how closely the paths hug the original pixel grid, and at 1,600 pixels that is closer than the photograph deserves.
Two corrections are applied to what the tracer emits. It writes width and height in pixels and no viewBox, which produces a file that is technically vector and practically fixed-size — dropped into a page it refuses to scale, which is the one thing you converted it for. A viewBox goes in.
It also omits the XML namespace on the root element. Inside an HTML document a browser infers it and the file looks fine, which is how the problem survives untested. Opened on its own or handed to Inkscape or Illustrator, an SVG without that attribute is not an SVG at all, so it is written in.
The page shows you the size of what you dropped and the size of what came out, and that comparison is a better verdict than any preview. A traced result several times larger than its source means the algorithm found no flat regions and manufactured thousands of tiny paths instead — no setting fixes that, because the picture is the problem.
When it goes the other way, you have what you came for: a handful of clean paths, editable in any vector tool, ready for a cutter, an engraver or a print at any size. Keep the HEIF regardless, since this site can read that format and cannot write it, and every retrace starts from the original.
Filled shapes, and only filled shapes. Each region of similar colour becomes a closed path with a solid fill, so what you open in a vector editor is a stack of coloured silhouettes rather than the layered, named, stroked artwork a designer would have drawn.
Text is the case that surprises people. Letters in the photograph become shapes shaped like letters — they are not text, they cannot be edited, respelled or restyled, and they carry no font. If the mark you traced contains a wordmark and you need to change the wording, the trace has given you a picture of the words, and the type has to be set again in the editor.
A cutter, engraver or embroidery machine follows outlines, so the useful preparation is reducing the number of them. Trace at four colours, open the result, and delete the stray shapes that came from noise or shadow — there are usually a handful, and they are the ones a cutting machine will faithfully cut.
Two more habits pay for themselves. Check that the shapes are closed and that holes in letters like A and O are genuinely holes rather than separate filled discs, because a cutter treats those differently. And set the physical size in the editor rather than assuming the trace has one: the SVG carries a viewBox and proportions, and the millimetres are your decision.
| HEIF | SVG | |
|---|---|---|
| Full name | High Efficiency Image File Format | Scalable Vector Graphics |
| File extension | .heif | .svg |
| Media type | image/heif | image/svg+xml |
| Compression | Lossy — file size is bought with quality | Uncompressed |
| First published | 2015 | 2001 |
| Published by | MPEG | W3C |
| Specification | ISO/IEC 23008-12 | SVG 1.1 |
| Licensing | Published, not standardised | Open standard |
| Standing today | Current | Current |
| Bit depth | 10 | — |
| Colour it can describe | YCbCr, wide gamut | RGB |
| Opens in a browser | Some browsers | Every browser |
| Considered instead | JPG, AVIF | PNG, PDF |
Transparency survives. Both HEIF and SVG store an alpha channel, so a cut-out stays cut out and nothing is filled in behind it.
Animation survives. HEIF and SVG both hold multiple frames, so the result moves rather than freezing on the first one.
SVG is a working format and HEIF is a finished one. What comes back is editable text and objects rather than a picture of a page, which is usually the reason for the conversion and also where its limits are.
SVG opens in every current browser. HEIF has narrower browser support than that. If the file is going onto a web page or into a form, that is usually the whole reason for the conversion.
The result is larger than the original and no better. HEIF has already discarded detail, and SVG stores what is left without discarding more — it prevents further loss rather than undoing the first one.
The two are aimed at different work: HEIF at phones and photography, SVG at the web, line art and logos and editing. That is worth weighing before converting, because the reason one exists is usually the reason the other is awkward.
HEIF is MPEG's format, published in 2015. It records 10 bits per channel.
SVG comes from W3C and dates from 2001, specified as SVG 1.1. Inkscape, Adobe Illustrator and Figma all read it.
No. This conversion runs entirely inside your browser, so the file never leaves your device. You can confirm it yourself: open the network tab of your browser's developer tools and convert something. You will see the page load, plus the analytics and advertising the site is paid for with — and nothing carrying your file. The engine behind this particular pair is libheif, the reference decoder for Apple's HEIC; your browser fetches it once and caches it.
It will produce an SVG and you will not want it. Tracing works by finding boundaries between areas of flat colour, and a photograph has none — measured before this shipped, a photograph came out about four times larger than the source and visibly posterised.
Flat artwork. A logo round-trips faithfully: 6 KB of source became 16 KB of SVG in testing, with sharp edges, correct colours and rounded corners intact, and it now scales to a billboard. Signs, stencils, stamps and line drawings behave the same way.
Four for a single-colour mark or a stencil, eight for a flat illustration, sixteen or thirty-two when there is shading you need to keep. More colours means more paths and a larger file, and on a photographed subject it mostly means more noise.
How closely the paths follow the pixels. Smooth accepts a looser fit and discards any shape smaller than sixteen pixels, which clears the specks antialiasing leaves along an edge. Sharp keeps shapes down to two pixels and follows the outline closely, including its flaws.
Yes. The XML namespace is written into the root element, which the tracer itself omits — a browser infers it and every real SVG tool refuses the file without it. A viewBox is written too, so the drawing scales instead of sitting at a fixed pixel size.
Compare the two file sizes, which the page shows you. A traced result several times larger than the picture it came from is the reliable sign that the source had no flat regions to find, and no setting will rescue it.
The claims this page makes about HEIF and SVG are checkable, and these are the documents that settle them.