First, the string already is a file
A Base64 string is not format-neutral. It is one particular kind of file, already encoded. The first bytes name it: a PNG opens 89 50 4E 47, a JPEG opens FF D8 FF, a WebP opens RIFF and carries WEBP at offset 8, a BMP opens 42 4D, and an SVG is not binary at all — it is text. Searching for “Base64 to PNG” does not turn a JPEG into a PNG.
One trap worth knowing before you trust a header: a PNG can advertise an alpha channel and contain no transparency whatsoever. My 640 × 360 sample is colour type 6 — truecolour with alpha — and all 230,400 of its pixels are fully opaque. The header describes the container, not the picture.
What PNG costs, measured
PNG is lossless, so it can never add detail the source did not already have. Every conversion below was run in Chromium on this machine by decoding the string, drawing it to a canvas and re-encoding, then comparing the pixels against the original.
| The string you start with | Bytes | Saved as PNG | Ratio | Pixels |
|---|---|---|---|---|
| PNG, 640 × 360 | 5,879 | 11,960 | 2.03× | identical |
| JPEG, 640 × 360 | 15,084 | 71,144 | 4.72× | identical |
| WebP, 640 × 360 | 9,254 | 48,856 | 5.28× | identical |
| PNG, 1 × 1 | 88 | 88 | 1.00× | identical, byte for byte |
Two rows deserve a second look. Converting a JPEG to PNG produced a file 4.72× the size with pixels identical to the JPEG — that is a lossless copy of an already-lossy picture, so it bought nothing and cost 56 KB. And the PNG row went from 5,879 to 11,960 bytes with identical pixels, while the 1 × 1 PNG came back byte for byte unchanged.
That gap is the whole point: saving a PNG is free only when you are writing out the original bytes. Push it through a canvas and it becomes a new file from a new encoder. For the 640 × 360 image that new file was twice the size for exactly the same picture. So when the string is already a PNG, this page writes your bytes out untouched instead of re-encoding them.
Transparency is the one thing JPEG cannot do
JPEG has no alpha channel at all, which means a transparent pixel has to become some colour. Here is a 200 × 200 PNG with a soft edge and a semi-transparent square, saved four ways:
| Saved as | Bytes | Transparent pixels kept |
|---|---|---|
| Source PNG | 4,951 | 24,886 of 24,886 |
| PNG | 4,951 | 24,886 of 24,886 |
| WebP, quality 92 | 3,060 | 24,886 of 24,886 |
| JPEG, quality 92 | 3,565 | 0 of 24,886 |
| JPEG, white laid down first | 4,229 | 0 of 24,886 |
Not one transparent pixel survived JPEG, in either version. A pixel that was 0,0,0,0 — fully transparent black — came back as 0,0,0 when nothing was painted underneath, and as 255,255,255 when white was painted first. That is why the white-backed JPEG is 664 bytes larger: it is storing a solid white field that the transparent one left as black.
So “PNG or JPEG” is not a question about size alone. If the picture needs a transparent background and you must ship one flat file, your real choices are PNG and WebP — and here WebP was both smaller than the PNG and fully lossless about the transparency. Pick JPEG and you are also picking a background colour, so pick it deliberately rather than discovering it is black.
Re-encoding a JPEG is another generation, not a conversion
Saving an already-JPEG image as JPEG again changed 16,810 pixels, with the largest single channel shift at 20, and saved just 1.5% of the bytes — 15,084 down to 14,852. Dropping to quality 60 changed 44,065 pixels to save 45%. Every save of a lossy file is one more generation, and the detail it discards never comes back.
The same caution runs the other way too: taking that 640 × 360 PNG and writing it as JPEG at quality 92 changed all 230,400 pixels (largest channel shift 79) and produced a file 2.57× larger than the PNG it came from. Re-encoding can lose quality and gain bytes at the same time.
A vector source is text, and rasterising it is one-way
The SVG sample was 163 bytes of text describing a 120 × 60 graphic. Rasterised to PNG it became 1,314 bytes — eight times the size — and it stopped scaling. If your string is an SVG, save it as SVG unless something downstream specifically demands pixels.
What this page will not do
It will not tell you whether your string is damaged. That is a different question with a different answer, and it lives on its own page: if the string will not decode at all, Base64 to image works out whether it was cut short, lost a character, or lost its padding.
How these numbers were produced
Six source images, each decoded from Base64 and re-encoded through a canvas: a 640 × 360 PNG (5,879 bytes), the same picture as JPEG at quality 92 (15,084 bytes) and as WebP (9,254 bytes), a 200 × 200 PNG carrying 24,886 non-opaque pixels (4,951 bytes), a 1 × 1 PNG (88 bytes), and a 120 × 60 SVG (163 bytes of text). Every re-encoded file was compared against the decoded source pixel by pixel. Tests ran in Chromium on Windows, so treat the ratios as the shape of the trade-off rather than as constants for your own file — the live readout above measures your bytes specifically.