Initializing... drag & drop files here
Supports: TIFF, TIF
This converter vectorizes. The image is handed to a raster-to-vector tracer, which groups pixels into colour regions, fits curves to the boundaries between them, and writes real <path> elements into the output. Nothing is base64-encoded, and nothing is placed inside an SVG <image> element — the file you get back is genuine vector geometry that you can select, recolour, and reshape node by node in Inkscape, Illustrator, or Figma.
That distinction decides whether this conversion is right for your file. A trace approximates the source with paths, so the result is only as good as the fit. On flat artwork — a logo, a signature, a line drawing, a schematic, a high-contrast scanned stamp — the fit is excellent and the SVG is a handful of kilobytes that scales forever. On a photographic scan it is not: continuous tone has no clean boundaries, so the tracer either flattens the picture into a few lumpy colour blobs or emits tens of thousands of micro-paths, producing an enormous SVG that is slow to open and looks worse than the TIFF you started with. Photographic scans belong in TIFF to PNG or TIFF to JPG, not here.
TIFF is not one of the tracer's native input formats — those are PNG, JPG/JPEG, JFIF, BMP, GIF and WebP — so a TIFF has to be rendered to a standard raster before any tracing can happen. Doing that step yourself is worth considering as a quality decision rather than a chore: developing the scan gives you control over crop, contrast, levels, and output size, and those choices affect trace quality far more than any slider on this page does. Render the file with TIFF to PNG, look at the result, push the contrast until the shape you care about separates cleanly from its background, then trace that with PNG to SVG.
<svg> tag, and CSS can restyle its fills.| Property | TIFF | SVG |
|---|---|---|
| Type | Raster (pixel grid) | Vector (XML-described shapes) |
| First published | 1986 (Aldus rev 3.0) | 2001 (W3C SVG 1.0) |
| Maintainer | Adobe (since 1994) | W3C |
| Browser support | Safari only inline; Chrome/Firefox/Edge need a plugin | Native in all modern browsers |
| Compression | None / LZW / ZIP / JPEG / CCITT G4 | gzip (when served as .svgz); paths are inherently compact |
| Scalability | Resolution-fixed; resampling blurs | Traced paths stay sharp at any zoom |
| Multi-page | Yes (one of TIFF's signature features) | No native multi-page; one document per file |
| Editable in code | No (binary tags) | Yes (plain text XML) |
| Colour models | RGB, CMYK, LAB, grayscale, indexed | Flat sRGB fills, one per traced region |
| Typical use | Print, archival, scanning, satellite imagery | Web icons, logos, diagrams, charts, UI |
| Source content | Expected result | What to do |
|---|---|---|
| Single-colour logo, stamp, or signature | Excellent — a few clean paths, a few KB | Trace at precision 3-5 and tidy stray nodes in Inkscape |
| Line art, blueprints, schematics | Very good — sharp edges trace cleanly | Trace at 4-6; raise toward 7-8 only if thin lines break up |
| High-contrast poster or graphic | Stylised but faithful, limited colour regions | Trace at 3-5; expect flat fills, not gradients |
| Photographic scan (people, landscapes) | Poor — huge file, no fidelity gain | Keep it raster: TIFF to PNG or TIFF to JPG |
| Scanned text document | Poor — letterforms become outline shapes, not text | Use OCR and TIFF to PDF instead |
| Precision | What it does | When to use |
|---|---|---|
| 1-3 | Few colour regions, heavily smoothed curves | Silhouettes and single-colour marks; smallest possible output. Fine texture disappears |
| 4-6 (default 6) | Balanced clustering and curve fitting | The recommended band, and where the on-page note points. Right for almost every case |
| 7-8 | More colour separation, more nodes per path | Technical drawings where thin lines must survive. Above 6 the extra decimals mostly add bytes |
| 9-10 | Nothing — the run aborts with no file | Never. Colour precision caps at 8 and the same value feeds it, so the job errors out instead of tracing |
Yes. The output is real <path> geometry produced by a raster-to-vector tracer — it is not your TIFF wrapped in an SVG <image> element, and there is no base64 payload inside the file. That is why the result scales without blurring and can be edited shape by shape. The honest limit is that a trace is an approximation of your pixels, so it shines on flat artwork and fails on photographs.
For logos, signatures, and line art, dramatically smaller — often a few kilobytes against a multi-megabyte scan, because describing a shape costs far less than storing a pixel grid. For a photographic scan, expect the opposite: every tonal step becomes its own filled path, and the resulting XML can outweigh the source. A traced photo that comes back larger than the TIFF is the signal that this was the wrong tool for that image, not a setting to tune.
If the geometry is genuinely vector, it will stay sharp — a traced logo enlarged tenfold has no pixels to blur. What people usually notice on a photographic source is different: the shapes are sharp but wrong, because the tracer approximated smooth tone with hard-edged blobs. Sharpness at any zoom is only useful when the traced shapes were right to begin with.
Yes, and this is where tracing pays off. Both open SVG natively and show each traced region as an individual object: recolour a fill, delete a stray path, merge two neighbouring shapes, or drag nodes to clean up a curve. Traced scans usually benefit from a minute of tidying — small speckle paths from scanner noise are the most common thing worth deleting.
Eight is the maximum, even though the slider travels to 10. The value is sent to the tracer twice — once as the path precision, where 10 would be legal, and once as the colour precision, which is defined only for 1 to 8 significant bits per RGB channel. Asking for nine bits of colour is outside what an 8-bit channel can hold, so the tracer rejects it outright and the job ends with nothing to download. Nothing is lost by staying below it: above about 6 the extra decimals are far smaller than anything a renderer will ever draw.
Not as a single file — SVG has no multi-page concept, so there is no way to return a multi-page document as one .svg. If a specific page matters, split the TIFF first (ImageMagick's convert input.tif page-%d.tif does it in one line) and upload just that page. If your goal is keeping the pages together at all, TIFF to PDF is the right target — PDF preserves page order in one output.
They are reduced to 8-bit sRGB before tracing, and then reduced much further by the trace itself: the output is a set of flat fills, one per detected colour region, so neither wide-gamut data nor subtle tonal transitions survive in any form. That is fine for a spot-colour logo and useless for a press master. Keep the original TIFF for archival work and use TIFF to PDF with a print-ready profile when colour fidelity is the point.
For displaying a picture, TIFF to PNG or TIFF to JPG is almost always the better answer. Choose SVG when you specifically need the artwork as shapes: editable paths in a vector tool, geometry a cutter or engraver can follow, markup you can inline in HTML and restyle with CSS, or an asset that must scale to any size without a resolution decision.
Yes — SVG to TIFF rasterizes the SVG at a chosen resolution and writes a TIFF. Note that the round trip does not recover your original scan: what comes back is a rendering of the traced shapes, so it will look like the trace, not like the photograph or scan you first uploaded. Keep the source TIFF if you may need the real pixels again.
Check Number precision first, since 9 and 10 stop the run outright. If it was already at 6, the usual cause is a low-contrast scan: a faint pencil drawing or a washed-out grey background gives the tracer no colour boundary to find, so it returns one large flat region. Render the file with TIFF to PNG, raise the contrast until the subject clearly separates from the paper, and trace that with PNG to SVG.