Labs · Card slimmer
Shrink the card.
Don’t kill it.
An 8MB card PNG won’t fit the upload limit — and every ordinary compressor strips the text chunks where the character actually lives. This one re-encodes only the artwork, re-embeds your card data untouched, and proves it: the chunks are byte-verified against the original before you ever see a download button.
Drop a PNG character card here, or click to choose
.png (card image with chara / ccv3 chunks)
Decoding, quantization, re-embedding and verification all happen in your browser — nothing uploads, nothing is stored. Works offline once loaded.
The slimming result appears here.
How do you compress a PNG character card without breaking it?
Split the file into what it really is: artwork plus a payload. The chara / ccv3 chunks are lifted out of the original file as raw bytes — never decoded, never re-serialized. The artwork alone goes through the pipeline (downscale, quantize to a palette, re-encode as an indexed PNG), and the untouched chunks are spliced back in before the first image-data chunk, exactly where readers expect them. SillyTavern-family importers, Foreverse included, read the result like any other card — because as far as the card data is concerned, nothing happened.
What it can’t do (the honest part)
The card data itself is a floor: a card whose JSON weighs 900KB can never shrink below that, no matter what happens to the art — the tool shows you that floor up front. Quantization is lossy by definition: 256 colors is near-invisible on character art, 64 shows banding, and the tool says which is which instead of calling everything “high quality”. APNG animations survive only as their first frame. And a browser encoder won’t out-compress a dedicated optimizer on an already-crushed file — when the output comes out bigger, the tool tells you to keep the original.
FAQ
Why can't I just run my card through TinyPNG / Squoosh / an image compressor?
Because they're built for images, not cards. Re-encoding a PNG rebuilds it from pixels and throws away the text chunks (tEXt / iTXt / zTXt) — and that's exactly where the chara / ccv3 card data lives. The picture survives, the character dies. This tool re-encodes only the artwork, then splices the original card chunks back in, byte-for-byte untouched.
How do I know the card data really survived?
It's verified, not promised: before the download button appears, the tool extracts the card chunks from the output and compares them against the original byte by byte. If they don't match exactly, you get an error instead of a download. The check runs on every single compression.
What does the quality tier actually do? PNG has no “quality” slider.
Correct — the canvas PNG encoder has no quality knob (that only exists for JPEG/WebP), and a card must stay a PNG because the data chunks can only live there. So the quality tiers are palette quantization: the artwork is reduced to 256 / 128 / 64 colors with Floyd–Steinberg dithering and written as a real indexed-color PNG. On character art the 256-color tier is near-invisible and typically halves the file.
Why did my file get bigger instead of smaller?
Two honest reasons: the original was already crushed by a pngquant-class optimizer (a browser can't beat that at the same settings), or it's already an indexed-color image and the lossless tier expanded it back to full color. The tool tells you when this happens instead of hiding it — try a smaller size tier, a harder quality tier, or accept that this particular card doesn't need slimming.
Is my card uploaded?
No. Decoding, quantization, chunk splicing and verification all run in your browser with local APIs. Nothing is sent anywhere, and the page works offline once loaded.