Notes › Resources › PNG to SVG still blurs when enlarged: what vectorisation can and cannot do

PNG to SVG still blurs when enlarged: what vectorisation can and cannot do

A client wanted a homepage mark for a site and sent a 240×240 PNG, saying it was the official logo and could be scaled up without a problem. I converted it to SVG and delivered, and the hero section stretched it to 1200 pixels wide with a ring of jagged edges all the way round. The client asked: I thought SVG could be scaled to any size?

I eventually reduced the answer to one sentence: whether an image can be scaled up depends on what the SVG file contains, not on the extension.

Bitmap and vector differ in how they record, not in sharpness

A bitmap (PNG, JPG, WebP, GIF and BMP all qualify) records a colour value at every position. Its dimensions are the ceiling: put a 512×512 image into 5120×5120 and every original pixel has to cover a 10×10 square, with the colours in between calculated by interpolation, so the edges either soften or turn into steps.

A vector records a geometric description: shapes, paths, anchor points, fills. It has no native size; it is calculated for the current view when rendered, so 1200 pixels wide and 12000 pixels wide use the same data.

So the phrase PNG to SVG hides two completely different routes. One is wrapping: embed the bitmap as it is inside an SVG file, with a vector container around it. The other is tracing: actually generate paths. A wrapped image scales exactly like the original PNG; only tracing gets you the vector advantage.

Approach What the SVG holds Edges at 5x File size Can one colour be changed on its own
Wrapping (embedded bitmap) The original pixel data, encoded into an image element Still interpolated; no extra detail appears About a third larger than the original PNG No, the whole thing is one bitmap
Tracing (paths) A number of paths and fill colours Clean edges, outlines recalculated geometrically Depends on the number of paths and nodes Yes, each colour patch is selectable
Redrawing by hand Paths drawn as needed Clean Usually the smallest Fully controllable

The figure of about a third larger in the third row can be calculated: embedded data goes through an encoding such as Base64, and the character count is about 4/3 of the original bytes, so the file ends up roughly thirty percent bigger than the source image. The conversion loses no quality; the price is size.

Three settings cap what tracing can do

I have tried a good number of tracing tools, and the knobs come down to these three. Understand them and you will not expect the wrong thing from the result.

  • Threshold: the line that splits greyscale into black and white. Move it up or down a little and the silhouette gets thicker or thinner. Binary tracing can only produce flat shapes, so a photo with tonal range is guaranteed to lose information here.
  • Number of colours: how many colours may take part in the output. At 4, 8 and 16 colours the fidelity rises step by step, but so does the number of paths, and you can end up with thousands of colour fragments that are harder to edit than the original.
  • Nodes and smoothing: how tightly the outline follows the edges in the original. Follow too closely and every jagged edge and speck of noise is traced faithfully; loosen it and the shape turns smooth but the detail smears.

Treating these three as image-quality sliders is where most disappointment comes from. They adjust the fitting strategy; they cannot invent detail that was never in the original. Images suited to tracing share a few features: few colours, clear boundaries, no continuous gradients, such as flat logos, text, stamps, silhouettes, line art and pixel-style graphics. The unsuitable ones are just as clear: portraits, landscapes, realistic illustrations with shadows and gradients, and high-frequency texture such as hair and smoke.

When I still convert a PNG to SVG

Wrapping is not useless, and there are cases where I specifically want it:

  1. An SVG project needs bitmap assets embedded and the format has to be uniform SVG; what I need there is a container, not paths.
  2. I want a container version that loses no original quality, leaving scaling to the view size while the bitmap stays untouched and no second encoding pass is applied during conversion.
  3. Image assets have to be handed to a web page or a vector editor as SVG, with size and layout decided downstream.

In those cases I use Image to SVG, which takes PNG, JPG, WebP and similar formats and can process a batch. The feature that matters most for judging whether scaling will blur is actually another one: after generating, you can look at the SVG source directly. If the source shows <image> plus a long encoded string, or <path> plus coordinates, the conclusion is immediate, instead of waiting until launch to see jaggies in the hero image.

If the real need is a larger bitmap, the direction is entirely different and the job is pixel resizing. I use Image Resizer for that. It will not add detail either, but at least it outputs an unambiguous bitmap, and I do not have to explain why the container changed while the edges did not. When I already have an SVG but have to deliver a bitmap format, I use SVG Converter to go the other way.

How that delivery ended

The client's logo was three characters inside a ring, three fill colours in total. I did not waste time on tracing settings; I drew the paths by hand from the original, under 100 nodes, and it took forty minutes. At hero size the edges are clean, the colours can be adjusted separately, and the file is smaller than the PNG.

If it had been a realistic icon with gradients and shadows, that option would not exist. The right answer then would be to ask for the source file, AI, SVG or at least a high-resolution PNG, rather than hoping some conversion setting will save it.

Q: It is still blurry after converting to SVG. Did the conversion fail?

Not necessarily. Open the SVG source and look: if it holds an embedded bitmap, it is wrapping, and scaling behaves like the original by definition. Only when paths have actually been generated can you talk about vector scaling.

Q: Can a photo be vectorised?

Paths can be generated, but the result is usually not what you want. The gradients in a photo make tracing produce thousands of fragment patches, a huge file that cannot be edited. If you really need a bigger photo, the answer is more resolution or a reshoot, not a different format.

Q: Does raising the threshold make it more precise?

The threshold changes what is kept, not the precision. On silhouette graphics it is a useful knob; on an image with tonal range, moving it either way throws away the other end of the range.

Q: Is the SVG smaller than the PNG?

Wrapping is usually larger, because the encoding overhead is about a third. A low-colour graphic traced into paths can shrink noticeably, while photo-like images usually grow.

Q: For print, is converting to SVG enough?

No. If the SVG holds a bitmap, print resolution is still limited by the original pixels. My rule: a print file needs either paths or a bitmap of at least 300dpi; if it has neither, it has to be redone.

The client's question is answered at this point: SVG is not a synonym for high definition, it is a container and a way of describing an image. My process now includes one hard check: before delivery, open the source and confirm whether it holds path or image, and tell the client how far that image can be scaled. Extensions can lie; source code does not.

📎 Related articles

SOS is 9 tones, the full alphabet is 104: how Morse timing is calculated 2026-10-21 What does a weight of 30 mean on a spinner? Sector angles and draws with or without replacement 2026-10-21 Why white text on gradients is hard to read: checking WCAG contrast at every stop 2026-10-21 Enlarging old photos without blur: how much detail enhancement can recover 2026-10-15 Barcodes for inventory labels: choosing between CODE128 and EAN-13 2026-10-15