The PNG File Structure
The PNG format was developed by a team including Thomas Boutell and Guy Eric Schalnat, and was first released in 1995. According to the PNG specification document (ISO/IEC 15948:2003), the format supports up to 16 million colors and lossless compression, making it ideal for storing character card data without quality degradation.
A PNG (Portable Network Graphics) file is not a monolithic block of data. It is composed of a signature followed by a series of 'chunks.' Each chunk has a specific purpose: IHDR contains image dimensions, IDAT contains the actual pixel data, and IEND marks the end of the file. Our interest lies in the 'ancillary' chunks.
Understanding this structure is important because it explains why character cards can be so large. The pixel data takes up most of the space, but the metadata can also be significant, especially for characters with long dialogue examples. When you see a character card that's 2MB or larger, it's usually because the metadata is uncompressed or the image is high resolution.
Ancillary Chunks: tEXt, zTXt, and iTXt
The PNG specification allows for optional metadata chunks. The tEXt chunk stores uncompressed strings, while zTXt uses zlib compression to save space. These chunks were originally intended for things like copyright info or software tags, but the AI community has co-opted them to store complete character definitions in JSON format.
The difference between tEXt and zTXt matters for character cards. tEXt is simpler but takes up more space. zTXt is more complex but can store much larger amounts of data in a smaller file. Most modern character cards use zTXt because they often contain thousands of lines of dialogue. Our converter handles both formats automatically, so you don't need to worry about which one your card uses.
The Parsing Process
When you upload a card, our JavaScript engine performs a binary sweep of the file. We search for specific keywords within the chunk headers—most commonly 'chara'. Once found, we must determine if the payload is raw text or if it needs to be inflated using the Web Decompression API. This 'Zero-Server' approach requires high-performance binary manipulation directly in the browser's memory.
The parsing process is where most converters fail. They don't handle edge cases like malformed chunks, missing CRC codes, or compressed data that's been corrupted. Our converter is designed to handle these cases gracefully, so you don't get cryptic error messages. Instead, you get clear feedback about what went wrong and how to fix it.
Why Binary Alignment Matters
Improperly saved PNGs can have misaligned chunks or missing CRC (Cyclic Redundancy Check) codes, which can cause frontends to crash. Our converter ensures that every card we export is 'spec-perfect,' with correct binary headers and metadata alignment, ensuring 100% compatibility across all major AI frontends.
CRC codes are like checksums. They verify that the data in a chunk hasn't been corrupted. If a CRC code is missing or incorrect, the frontend might refuse to load the card. This is one of the most common reasons why character cards fail to load, and it's something our converter handles automatically. You can verify this yourself by checking the binary output of our converter — every exported card includes proper CRC codes.
Coming Soon: CharacterCardGenerator
We are building CharacterCardGenerator.com to help you create character cards with proper binary alignment. Instead of manually editing JSON or using clunky editors, you'll describe your character in plain English and get a properly formatted card in seconds. It will handle all the technical details, including CRC codes and binary alignment. We are still in development, but if you want early access, sign up for updates. It will be free to start with a credit system for power features.