Which image formats can a paper animator actually read?

There is no format list — there are two gates

The honest answer to "which formats can I use" is not a list of names. It is two gates in a row, and only the first one belongs to this tool.

The first gate is a type check, and it is the only hard-coded rule in the whole intake path. The file's type has to begin with image/. Nothing else is inspected at that point — not the extension, not the file name, not a table of approved formats. A file that arrives as image/bmp passes the gate just as easily as one that arrives as image/png.

The second gate is the browser's decoder, and this is the part most tools never mention. Whatever survives gate one is handed to the engine you are already running. If it can decode the bytes, the image loads. If it cannot, you get a refusal — and it is a different refusal from the one gate one produces, which turns out to be genuinely useful.

• Gate one — the type. A file whose type does not start with image/ is stopped before a single byte is decoded.
• Gate two — the decoder. A file that passes gate one is decoded by your browser. The accepted set is therefore whatever your browser can read, not whatever the site decided to support.
• The picker is not a third gate. The file input on the page carries accept="image/*", so the picker offers whatever your system labels as an image. It filters nothing that gate one would not also catch.

What actually went in, measured on this machine

A claim about formats is worth nothing until someone puts files through the door. So seven files were built here and handed to the tool through its own load entry point — the same path a dropped file takes — and the status line under the canvas was read back each time.

Every line below is the page's own text, copied from the run. Nothing here is inferred from documentation, and no format was assumed to work because it usually does.

• PNG, 600×400 — Loaded 600×400 → working at 840×560.
• JPEG, 600×400 — Loaded 600×400 → working at 840×560.
• WebP, 600×400 — Loaded 600×400 → working at 840×560.
• GIF, 8×8, two frames — Loaded 8×8 → working at 512×512.
• GIF, 30×30, a 70,364-byte multi-frame file — Loaded 30×30 → working at 560×560.
• BMP, 4×4 — Loaded 4×4 → working at 256×256.
• SVG, 120×80 — Loaded 120×80 → working at 840×560.

The two refusals mean different things

There are exactly two ways in, and there are two ways to be turned away. They produce different sentences, and the difference is the most useful diagnostic the page offers, because it tells you which gate you failed.

Both were produced deliberately here. A plain text file was handed over once with its own type and once with the type quietly changed to image/png. The first run was stopped at gate one; the second run passed gate one and then failed to decode, which is exactly what should happen to a file that lies about what it is.

• Wrong type — That file is not an image. Try PNG, JPEG, WebP or GIF. You are being told the file did not arrive as an image, which usually means it was exported as a document, a PDF or a project file by mistake.
• Right type, unreadable bytes — Could not decode that image. Try PNG, JPEG, WebP or GIF. You are being told the file claimed to be an image and the decoder could not read it, which usually means the file is truncated, corrupted, or in a format this particular browser build does not carry.

GIF goes in, and one frame comes out

GIF is the format that surprises people, because it is the one format here that can hold motion and the tool is built around a still. Both of the GIF files tested above loaded cleanly. Neither brought its motion with it.

The reason is in how the intake path is written. Decoding produces a single drawable object and the page keeps exactly that one object — one bitmap, held in one variable. Everything after that point is drawn from it. There is no frame index, no frame stepper, and no second decode pass, so a file with two frames and a file with two hundred frames arrive at the same place: one picture.

That has a practical consequence worth knowing before you start. If you want a particular moment from an animated GIF, the tool will not choose it for you, because it has no way to ask. Take the frame you want out of the animation first, in something that can scrub it, save that frame as a PNG, and bring the PNG in. The still will load at its own size and the tear will be built over it.

Three decode routes, and why each one is tested before it is trusted

Behind gate two there is not one decode attempt but three, tried in a fixed order. This is the part of a format story that almost never gets published, and it is the reason an unusual file can still work.

The order is deliberate. An image element pointed at a temporary local URL goes first, because that route is the one every engine can draw. A bitmap created directly from the file goes second. A data-URL round trip goes third. Each candidate is then put through a real test rather than being assumed good: it is drawn into a one-pixel canvas and the pixels are read straight back out. Only if both halves of that succeed is the candidate accepted.

That test exists because some engines hand back an object that reports a size and then refuses to draw. Without the probe, a file would decode, pass every check, and then produce a blank canvas with no explanation. And if all three routes fail the probe, the page does not give up: it hands forward the best candidate it did manage to decode and lets the render path report what actually happened, rather than blaming the file for a fault that was not its own.

• Route one — an image element pointed at a temporary object URL created from the file.
• Route two — a bitmap created straight from the file, used where the engine provides it.
• Route three — the file read as a data URL and loaded into an image element.
• The probe — each candidate is drawn at one pixel and the result read back, so an object that cannot really be drawn is rejected rather than trusted.

Format is not the last thing that decides what you get

Getting a file through the door is only the first decision. The next one is size, and it is made for you.

Whatever format arrives, the image is fitted to a working canvas whose long side is capped at 1600 pixels, and small images are scaled up rather than down so that the torn edge has room to exist. That is why the three 600×400 files above came back as 840×560 instead of staying where they were, and why a 4×4 BMP came back as 256×256. The status line always reads both numbers back, so the size you sent and the size being worked on are both in front of you.

So a format question and a size question are separate questions. The format decides whether the file gets in at all. The size decides what the tool has to work with once it is in, and the page tells you the second one every single time rather than leaving you to find out at export.

The short version

There is no list of blessed formats to memorise. A file goes in if its type starts with image/ and the browser in front of you can decode it — measured here as PNG, JPEG, WebP, GIF, BMP and SVG all loading, with a text file refused twice in two different ways. GIF is accepted but contributes a single frame, so take the frame you want out first. And once a file is in, the working size is capped and small images are scaled up, with both numbers printed under the canvas.