So what format did you download?
Open the download in a hex editor and the first bytes read 89 50 4E 47. That is PNG's signature, not GIF's. The extension lied. The bytes did not.
Canvas elements in Blink, Gecko and WebKit all guarantee exactly one export format: PNG. JPEG and WebP show up as extras in most of them. GIF never made the list in any of the three, because nobody wrote a GIF encoder into the canvas specification. Ask a browser to export image/gif anyway and the spec tells it what to do about that: fall back to PNG and say nothing, unless the page checks the blob's reported type itself. This page checks, and the badge above only appears when the fallback fires, which today is every time, on every browser.
GIF against what you are holding
Line up the two formats and the gap is not subtle.
| Property | Real GIF file | What this page hands you |
|---|---|---|
| Color palette | 256 colors max, indexed | Full 24 or 32 bit color, untouched |
| Compression | LZW, lossless inside that palette | PNG's DEFLATE, lossless across the full range |
| Frames | One or many, built for animation | One, always |
| Transparency | A single fully transparent color per frame | Full alpha channel, byte by byte, if the BMP carried one |
| Fits best | Flat art, icons, short loops | Anything a PNG already handles well |
Where the megabytes went
A bitmap never compresses a single pixel. Take a 1280 by 720 photo at 24 bits per pixel: each row costs 3840 bytes of color, already a multiple of four, times 720 rows, and you are holding 2.76 MB before the file header is even added. Send that same picture through as a full color PNG and DEFLATE finds the redundancy a camera photo always carries, which typically lands the result under a third of the bitmap's weight. None of that is GIF's palette trick. It is PNG doing what PNG does, nothing more.
Odd widths waste more than you would guess. A 641 pixel wide row at 24 bits needs 1923 bytes of color, padded up to 1924, so four pixels' worth of padding rides along on every row for nothing.
When a real GIF earns its place
- Pixel art and flat icons. Few colors, hard edges, no gradients to band. This is the case GIF was built to store well.
- Short animated loops. The animated mode on PNG to GIF builds real multi frame files with an actual LZW encoder, not a canvas fallback. This page only ever produces one frame.
- Software that checks the file signature. Some upload validators, older CMS platforms and embedded systems read the first bytes and reject anything that is not truly a GIF, extension or not.
- Line art and diagrams. Where 256 colors is not a limit at all, GIF's overhead is close to zero.
Circumstantial upside
One thing worth knowing before you dismiss the mismatch: because the fallback lands on PNG, a 32 bit bitmap with a true alpha channel keeps every value between fully clear and fully opaque. A genuine GIF would have thrown that away and kept one on or off transparent color instead. In this one respect, the file you download is a better container than the format printed on its own extension.
Where this stops
- One file at a time. There is no batch queue here. For a folder of images, the image format converter handles bulk work.
- No animation, ever. Whatever the source, the output is a single still frame.
- No palette reduction happens. Without a real GIF encoder running, there is no 256-color quantizing or dithering to speak of. A file that genuinely needs an indexed palette wants a dedicated encoder, not this converter.
- Run length encoded or embedded bitmaps fail to decode. BI_RLE8, BI_RLE4, BI_JPEG and BI_PNG bitmaps are outside what a browser canvas will open. BMP to PNG reads those.
- Memory sets the real ceiling. A decoded canvas costs width times height times four bytes, so a 10000 by 8000 pixel scan needs over 300MB before conversion even starts.
