Convert PPM to SVG
This is a raster-to-vector trace, not a container change. A PPM is a grid of raw RGB samples with no shape information in it at all; an SVG is an XML document describing paths and fills. The converter reads your pixmap, clusters neighbouring pixels of similar colour into regions, and redraws the boundary of each region as a Bézier path. That works beautifully on flat, high-contrast artwork — logos, icons, badges, line drawings, technical diagrams, screenshots of vector UI — and it works badly on photographs, where continuous tone collapses into stylised colour blobs and the file balloons.
PPM Format at a Glance
| Property | Value |
|---|---|
| Full name | Portable Pixmap, the colour member of the Netpbm family |
| Origin | Jef Poskanzer's Pbmplus toolkit; PGM and PPM added by the end of 1988 |
| Magic numbers | P6 (raw binary, standard) and P3 (plain ASCII decimals) |
| Structure | Text header — magic, width, height, maxval — then the raster, top-to-bottom, left-to-right |
| Bytes per sample | 1 when maxval is under 256, 2 (most significant byte first) when maxval is 256–65535 |
| Colour | RGB triplets, defined by the spec against ITU-R BT.709 primaries with a gamma transfer |
| Alpha channel | None |
| Colour profile / metadata | None — the spec calls the format "egregiously inefficient" and notes it "allows very little information about the image besides basic color" |
| Compression | None whatsoever |
| Best for | A working intermediate between image-processing tools |
SVG Format at a Glance
| Property | Value |
|---|---|
| Full name | Scalable Vector Graphics |
| Standard | W3C Recommendation; SVG 1.1 (Second Edition) published 16 August 2011, SVG 2 in progress |
| Payload | XML markup describing paths, shapes, fills, strokes and gradients |
| Resolution | None — geometry is resolution-independent and re-rasterised at whatever size it is drawn |
| Alpha channel | Yes, per-element opacity and RGBA fills |
| Editability | Opens as text; every traced path is individually selectable in Inkscape, Illustrator or Figma |
| Compresses well? | Yes — it is plain XML, so gzip/Brotli on a web server shrinks it substantially |
| Poor fit for | Photographs, gradients, soft shadows, film grain, anti-aliased scans |
How to Convert PPM to SVG
- Upload Your PPM File: Drop the
.ppmon the page or click "Add Files". Both Netpbm variants decode —P6binary andP3ASCII. Several files can be queued and traced with the same setting. - Set Number Precision: This is the only tracing control on the page. It is a 1–10 slider that starts at 6, and the on-page note recommends 4–6 for most work. Keep it inside 1–8 — the two highest positions abort the trace, as explained below.
- Check the Source Is Flat Artwork: Tracing rewards solid colours and hard edges. If the pixmap is a photograph or a gradient-heavy render, a raster target such as PPM to PNG will give a far better result than any precision value can.
- Convert and Download: Click Convert and save the
.svg. Files upload over an encrypted connection, are processed on our servers, and are deleted automatically after a few hours — no sign-up, no watermark, never shared.
What "Number Precision" Actually Controls
The slider is wired to two separate tracer parameters at once: colour precision, measured in significant bits per RGB channel, and path precision, measured in decimal places kept in each path coordinate. Raising it therefore does two things simultaneously — it lets the tracer distinguish more colours, and it keeps more digits per coordinate. Every other tracing parameter (speckle filtering, corner threshold, gradient step, curve mode) stays at the tracer's own defaults; this page does not expose them.
| Slider position | Colour bits per channel | Path decimals | Practical result |
|---|---|---|---|
| 1–3 | 1–3 | 1–3 | Heavy posterisation, very small file; useful only for near-monochrome art |
| 4–6 | 4–6 | 4–6 | The recommended band. Clean logos and line art trace tightly here |
| 7–8 | 7–8 | 7–8 | Maximum usable fidelity; more colour regions, more paths, noticeably larger XML |
| 9–10 | out of range | 9–10 | The trace fails and no file is produced |
Positions 9 and 10 are a genuine footgun on an otherwise working page. The tracing engine documents colour precision as "significant bits per RGB channel (1..=8)" — vtracer's own CLI reference — and 8 bits is the hard ceiling because that is all an RGB channel holds. Because the single slider feeds both parameters, asking for 9 or 10 decimal places in the path data also asks for 9 or 10 bits of colour, and the tracer aborts. We reproduced this: the job ends with nothing to download. Stay at 8 or below and the page behaves.
Frequently Asked Questions
Why does the conversion produce nothing at precision 9 or 10?
Because one slider drives two tracer settings. The value is passed as both the path precision (decimal places in coordinates, where 10 is legal) and the colour precision (significant bits per RGB channel, where the documented range is 1 to 8). Anything above 8 is outside what an 8-bit channel can express, the tracer aborts, and no SVG is written. There is no benefit hiding above 8 anyway — a coordinate with nine decimal places is far below the smallest difference any renderer will ever draw. Set the slider to 8 or lower.
Will my photograph look good as an SVG?
No, and no setting will rescue it. Vector paths describe flat filled regions; a photograph is continuous tone. The tracer has to quantise every smooth gradient into discrete colour bands, so skin, sky and shadow become stylised contour maps, and the file grows because each band needs its own path. That posterised look is sometimes a deliberate artistic effect, but it is not a faithful conversion. For photographic pixmaps use PPM to PNG for a lossless raster or PPM to JPG for a small one.
Why is my SVG bigger than the PPM I started with?
Because the tracer created a separate path for every colour region it found, and each path is verbose XML text. A noisy or gradient-rich source can easily produce tens of thousands of paths. Two things make it worse: anti-aliased edges (every intermediate pixel becomes its own thin region) and JPEG-style artefacts baked into the source before it became a PPM. Lower the precision to merge similar colours, crop tightly around the subject, or flatten the source to fewer solid colours before tracing. Note also that SVG is text, so a web server serving it with gzip or Brotli will transfer far less than the raw byte count suggests.
Does the SVG keep transparency from my PPM?
There is no transparency to keep. The Netpbm specification gives PPM three samples per pixel — red, green and blue — and no alpha channel at all, so whatever looks like a transparent background in your source is really a solid colour, usually white. The tracer will faithfully turn it into a filled path. If you want an SVG with a genuinely transparent background you will need to delete that background path afterwards in a vector editor, or trace a source format that carries alpha.
Is the output real, editable SVG or an embedded bitmap?
Real vector geometry. The output is standard XML-based SVG containing traced path elements, so it opens in Inkscape, Adobe Illustrator, Figma, Affinity Designer or any text editor, and every shape can be reselected, recoloured and reshaped. It is not a raster wrapped in an SVG envelope. Traces from flat sources are pleasant to edit because there are few, well-formed paths; traces from busy sources are technically editable but unpleasant, because you are dealing with thousands of overlapping fragments.
Which precision should I pick for a logo?
Start at the recommended 4–6 band and only move if the result is wrong in a specific way. If thin strokes, small type or fine serifs are disappearing, step up to 7 or 8 — more colour bits keep the near-identical shades of an anti-aliased edge apart, and more coordinate decimals keep the curve from being rounded off. If the SVG is enormous and full of jagged confetti shapes, step down instead: fewer colour bits merge those fragments into one region. Changing the source is usually more effective than changing the slider — a logo exported as flat colour with no anti-aliasing traces almost perfectly at any setting.
Can I trace several PPM files in one go?
Yes. Queue multiple .ppm files and they are traced with the same precision value, producing one SVG per input. There is no combining step on this page — tracing is per-file by nature, since two unrelated images have no shared coordinate space. If you need several traced graphics inside one document, convert them individually and then place them together in a vector editor, which also lets you set each one's position and scale.
Does the conversion happen on my machine or on your servers?
On our servers. Your PPM is uploaded over an encrypted connection, traced there, and the resulting SVG is returned for download; both the upload and the output are deleted automatically after a few hours, with no sign-up, no watermark and nothing shared or made public. Tracing is CPU-heavy on large or noisy images, which is exactly why it runs server-side — a big pixmap that would take a long time locally is handled without tying up your machine.
What is the largest PPM I should send?
The limiting factor is upload size and time, since PPM stores width x height x 3 bytes with no compression at all (doubled if the header's maxval is 256 or higher, because each sample then takes two bytes). A 4000 x 3000 pixmap is around 36 MB before you have done anything. Beyond upload, very large sources also make tracing slow and the SVG enormous, because path count scales with detail rather than with file size. If your image is big and detailed, downscaling it before tracing usually improves the SVG as well as the wait.