File Chunk Analyzer

Chunk-based file formats organize data into discrete, self-contained blocks called chunks. Each chunk typically has a header that specifies its type and size, followed by the data payload. This modular design makes it easy for applications to read specific parts of a file without parsing the entire thing - they can skip chunks they don't understand and process only the ones they need. Common chunk-based formats include PNG(Portable Network Graphics, which uses 4-byte type codes with CRC-32 checksums),RIFF (Resource Interchange File Format, used by WAV audio and AVI video, with recursive LIST chunks), JPEG (which uses 0xFF-prefixed marker segments), and GIF (with block-based structures including extensions and sub-blocks). Understanding chunk structures is essential for file forensics, data recovery, reverse engineering, and format compatibility analysis.

• PNG Format Structure: Every PNG file begins with an 8-byte signature (\x89PNG\r\n\x1a\n) followed by a sequence of chunks. Each chunk has a 4-byte length (big-endian), a 4-byte type code (e.g., IHDR, PLTE, IDAT, IEND), a data payload of the specified length, and a 4-byte CRC-32 checksum that covers the type code and data. The CRC-32 uses the ISO 3309 polynomial (0xEDB88320) and is computed over the chunk type + chunk data bytes. Critical chunks (IHDR, PLTE, IDAT, IEND) must appear in a specific order, while ancillary chunks (tEXt, gAMA, pHYs, etc.) can appear in any order between IHDR and IEND.
• RIFF Format Structure: RIFF (Resource Interchange File Format) is a container format where everything is organized as chunks. A RIFF file starts with a "RIFF" ID followed by a 4-byte size (little-endian) and a 4-byte form type (e.g., "WAVE", "AVI ", "WEBP"). Sub-chunks follow with their own 4-byte IDs and sizes. The "LIST" chunk type can contain sub-chunks with a list identifier. Data is aligned to 2-byte boundaries with padding bytes as needed. WAV files primarily use fmt (format) and data chunks, while AVI files use hdrl (header list), strl (stream list), movi (movie data), and idx1 (index) chunks.
• JPEG Marker Structure: JPEG files use marker segments identified by a 0xFF byte followed by a marker type byte. Each marker segment (except SOI 0xFFD8 and EOI 0xFFD9) has a 2-byte big-endian length field that includes the length bytes themselves but not the marker bytes. Key markers include SOF0 (Start of Frame with image dimensions), DQT (Define Quantization Table), DHT (Define Huffman Table), SOS (Start of Scan followed by entropy-coded data), APP0/APP1 (application data like JFIF headers and EXIF metadata), and COM (comment). The entropy-coded data after SOS continues until the next marker (0xFF followed by a non-zero byte).
• GIF Block Structure: GIF files use a block-based structure starting with a 6-byte header ("GIF87a" or "GIF89a"), followed by a 7-byte Logical Screen Descriptor, an optional Global Color Table, and then a sequence of blocks. Image blocks start with 0x2C, extension blocks start with 0x21 (followed by a label byte), and the trailer is a single 0x3B byte. Sub-blocks within extensions use a size-byte format where each block starts with a byte indicating the number of data bytes that follow. GIF89a supports Graphic Control Extensions (0xF9) for animation timing and transparency, Comment Extensions (0xFE) for embedded text, Plain Text Extensions (0x01) for text overlays, and Application Extensions (0xFF) for custom data like Netscape looping information.

1. Format Detection & Summary Overview: The tool first reads the file signature (magic bytes) to determine which format parser to use - PNG, RIFF, JPEG, or GIF. The summary banner at the top shows the detected format name, total chunk count, total data size, and structural overhead. This gives you an immediate overview of the file's composition and complexity.
2. Chunk List Navigation: The main chunk table lists every chunk found in the file, sorted by their byte offset. Each row shows the chunk type (with a color-coded badge), the descriptive name, the data payload size, and the byte offset location. Chunks with CRC validation (PNG) show a green checkmark for valid checksums or a red X for mismatches. Click any chunk row to expand it and view detailed field information with interpretations.
3. Field-Level Detail View: Expanding a chunk reveals a detailed breakdown of all parsed fields within that chunk's data payload. Each field shows its name, byte offset within the chunk, length in bytes, parsed value, and a plain-English interpretation of what the value means. For example, expanding an IHDR chunk shows width, height, bit depth, color type, compression method, filter method, and interlace settings. Expanding a GIF GCE chunk shows disposal method, delay time, and transparency settings.
4. CRC-32 Validation (PNG): PNG chunks include a 4-byte CRC-32 checksum at the end of each chunk. The tool recomputes this checksum from the chunk type and data bytes and compares it against the stored value. A valid CRC confirms the chunk data hasn't been modified since it was created. An invalid CRC indicates data corruption or intentional tampering. This is particularly useful for forensic analysis and file integrity verification.

Our File Chunk Analyzer processes everything locally in your browser. Files are read using the FileReader API and analyzed client-side using custom JavaScript parsers specifically written for PNG, RIFF, JPEG, and GIF formats. No data is ever uploaded to any server. The tool is 100% free with no signup, no account, and no usage limits.

Supported formats and their features: PNG files get full CRC-32 validation, field parsing for 20+ chunk types, and detailed IHDR/PLTE/tEXt/gAMA/pHYs/sRGB/ tIME analysis. RIFF files (WAV, AVI, WebP) get recursive LIST chunk parsing with fmt/data/avih/strh/strf field breakdown. JPEG files get marker-by-marker parsing with SOF0 dimension extraction, DQT/DHT analysis, APP0 JFIF header parsing, and COM comment extraction. GIF files get complete block parsing including color tables, GCE timing, comment/app extensions, and image descriptions.

Important limitations: The tool only supports the four formats listed. For other chunk-based formats (IFF, ILBM, AIFF, MIDI, FLAC, STL, 3MF), file header analysis is limited. Password-protected or encrypted files cannot be parsed. Very large files (over 50 MB) may take significant time to process. The tool performs structural analysis but does not decode compressed pixel data or audio samples - it analyzes the chunk structure and metadata only.

Best practices: Use this tool for quick structural inspection, CRC integrity checks, metadata extraction, and format education. For comprehensive analysis of encrypted, corrupted, or non-standard files, use dedicated forensic tools with more advanced recovery capabilities. Always verify critical findings with multiple analysis methods.