A file signatures list cheat sheet is a compact reference that pairs each common file format with its hexadecimal prefix — the fixed bytes that appear at offset zero of a real file. Twelve source-checked prefixes cover the formats developers actually meet in upload pipelines, incident response, and binary inspection: JPEG, PNG, both common GIF headers, PDF, ZIP, GZIP, 7-Zip, RAR 4, RAR 5, ELF, and SQLite 3. The sheet lists space-separated uppercase hex bytes so you can copy a value into a hex viewer, a libmagic rule, or an incident-analysis note without retyping from a different notation. Cheat sheet values are not always trusted; the prefix is one signal among several, and the most useful sheets label ambiguity directly instead of implying that a byte match equals a verified file type. A file signatures list cheat sheet is therefore best understood as a quick lookup, not a complete detector — a starting point that you pair with structural parsing, size limits, and security controls before accepting an upload.
What belongs in a file signatures cheat sheet
A useful cheat sheet has four columns: the format name (JPEG, PNG, ZIP), the file extensions commonly associated with it (jpg and jpeg, png, zip plus docx and xlsx and jar and epub), the exact hexadecimal prefix at offset zero, and a short note about ambiguity. The note is the most underrated column. ZIP's note is "container," because the same prefix appears in DOCX, XLSX, JAR, EPUB, and other Office Open XML packages; JPEG's note is "JFIF or EXIF variant," because JPEG can start with several legitimate headers depending on whether the camera wrote an EXIF block; PNG's note is "signature plus IHDR," because the eight-byte prefix is part of the PNG signature and is always followed by an IHDR chunk. A cheat sheet without these notes trains users to over-trust byte matches and to misroute DOCX files as raw ZIP downloads.
A complete reference also records the prefix length and flags the bytes as uppercase hexadecimal separated by spaces. The byte length tells you how much of the file you need to read before deciding, and the spacing convention lets you paste the prefix directly into a hex dump without reformatting. Sources worth cross-checking include the file command's magic database and the GCK file signatures table; both keep their entries under version control and document edge cases such as the old versus new RAR formats. The bytes 50 4B 03 04, the ZIP local-file header, are shared by every ZIP-based package, but RAR has changed its signature between versions 4 and 5, so the cheat sheet has to show both RAR 4 (52 61 72 21 1A 07 00) and RAR 5 (52 61 72 21 1A 07 01 00) instead of collapsing them.
| Format | Offset-zero hex prefix | Note |
|---|---|---|
| JPEG | FF D8 FF | JFIF or EXIF variant |
| PNG | 89 50 4E 47 0D 0A 1A 0A | Signature plus IHDR chunk |
| GIF87a | 47 49 46 38 37 61 | Older variant |
| GIF89a | 47 49 46 38 39 61 | Animated GIF variant |
| 25 50 44 46 | Header ASCII "%PDF" | |
| ZIP | 50 4B 03 04 | Container — also DOCX, XLSX, JAR, EPUB, APK |
| GZIP | 1F 8B | Stream, not record |
| 7-Zip | 37 7A BC AF 27 1C | Archive container |
| RAR 4 | 52 61 72 21 1A 07 00 | Legacy RAR archive |
| RAR 5 | 52 61 72 21 1A 07 01 00 | Current RAR archive |
| ELF | 7F 45 4C 46 | Linux or Unix executable |
| SQLite 3 | 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 | Header ASCII "SQLite format 3" |
How to look up and compare a prefix against the cheat sheet
- Search the File Signatures (Magic Bytes) List cheat sheet by format, extension, hex prefix, or note such as "container." This is faster than scrolling, especially when you already know the extension and want the bytes, or you already have the bytes and want the format.
- Open the suspect file in a trusted binary view such as xxd, hexdump, a hex pane in your editor, or a streaming hex viewer. Move to offset zero and read the first bytes.
- Compare those bytes against the cheat sheet row. A space-separated uppercase hex string from a maintained source drops directly into that comparison without reformatting.
- Copy the prefix into a detection rule, a documentation snippet, or an incident-analysis note. The exact spacing convention avoids mistakes when someone later pastes the value back into a regex or a constant table.
- Confirm the full structure with a maintained parser before trusting or processing the file. Treat the prefix match as a hypothesis, not a verdict.
Reading the first bytes of a suspect file
A practical workflow looks like this: an upload hits your pipeline, your server reads the first sixteen bytes, and you compare them against the cheat sheet row for the expected format. Suppose the upload arrived with the extension .pdf. You read the first four bytes, see 25 50 44 46, and the cheat sheet confirms that PDF starts with 25 50 44 46, the ASCII string "%PDF". You then check the next four bytes for the PDF version marker (2D 31 2E 34 for version 1.4, for instance) and look for the EOF marker (25 25 45 4F 46) near the end of the file. A prefix match alone is necessary but not sufficient — without the version line and the EOF marker the file may be truncated, corrupted, or a polyglot.
The same workflow applied to an image upload: you read the first eight bytes and check them against FF D8 FF for JPEG, 89 50 4E 47 0D 0A 1A 0A for PNG, or one of the two GIF signatures (47 49 46 38 37 61 for GIF87a, 47 49 46 38 39 61 for GIF89a). For archives, 50 4B 03 04 is the ZIP local-file header, 1F 8B is GZIP, 37 7A BC AF 27 1C is 7-Zip, 52 61 72 21 1A 07 00 is RAR 4, and 52 61 72 21 1A 07 01 00 is RAR 5. For native Linux binaries you read 7F 45 4C 46, and for SQLite databases 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 spells out the ASCII string "SQLite format 3". Each of these comparisons takes milliseconds, which is exactly why a cheat sheet pays off during triage.
Container ambiguity and what the prefix cannot tell you
The single most common mistake with a file signatures cheat sheet is reading the bytes 50 4B 03 04 and declaring "this is a ZIP archive." That is the ZIP local-file header, but it is also the prefix of DOCX, XLSX, PPTX, JAR, EPUB, APK, and many other ZIP-based packages. To identify the application format inside the container, a robust detector must read required internal package files ([Content_Types].xml for OOXML, META-INF/MANIFEST.MF for JAR, mimetype for EPUB) and check metadata, relationships, and the Content-Type declarations. The cheat sheet should flag this explicitly; if it does not, you will end up treating every DOCX as a generic ZIP download and breaking workflows that depend on the actual file format.
Container detection also has security implications. A ZIP-based file can be a decompression bomb, can contain path-traversal entries such as ../../etc/passwd, and can include active content such as macros or scripts. Identifying the container does not mean the contents are safe, and the byte prefix does not prove the contents are even well-formed. A reasonable upload pipeline accepts the prefix, opens the container with a maintained parser, enforces size limits before decompression, sanitizes entry paths, and serves downloads with Content-Disposition: attachment and a safe MIME type instead of inline rendering.
From cheat sheet row to production detection rule
Once you have the prefix and the note, you can encode the row as a detection rule. A constant lookup is the simplest form: a switch statement over the first four bytes that returns the expected format. That is fast and clear, and it is appropriate for upload pipelines that only need to refuse obviously wrong types. For richer detection, use a maintained library such as libmagic — its rules support indirect offsets, masks, numeric endianness, strings, and nested conditions. The cheat sheet covers only offset-zero prefixes; the file command's magic database covers the long tail of magic rules. If your rule lives in code, keep the source constant versioned, record the rule version alongside the verdict, and add regression samples that include both accepted formats and adversarial near-matches.
A second practical rule is to never authorize an upload solely because its prefix matches. The prefix could have been pasted at the start of a malicious payload, the file could be truncated, or the format could allow multiple signatures. Validate the complete file with a maintained parser, enforce an allowlist, rename the file server-side, isolate the storage, and block active content where appropriate. For higher-risk workflows, run antivirus or sandbox analysis before delivery. Detection libraries and decoders must stay current, and the rule should be tested against malformed, polyglot, oversized, and nested samples. Record both the observed bytes and the parser verdict so later reviewers can distinguish a prefix match from a validated file structure.
What the cheat sheet does not cover
A twelve-row cheat sheet is not the whole world. It does not include executable subtypes such as PE/COFF for Windows or Mach-O for macOS, media codecs (MP4, MKV, and WebM each use box or EBML structures that begin deeper in the file), disk images such as ISO 9660 whose Volume Descriptor starts at 0x8001, font files, mail formats, or every archive variation (TAR has no magic bytes at all; BZ2 is 42 5A 68 but only after two optional leading bytes). General-purpose libmagic covers those cases by reading bytes at other offsets, indirect offsets, masks, and strings. Use the cheat sheet as the high-frequency first pass, then consult a maintained library for the long tail, and re-check the format specification when implementing production detection.
The cheat sheet also does not scan your file. A reference such as the File Signatures (Magic Bytes) List tool runs in the browser, copies the displayed uppercase hexadecimal sequence, and never requests, reads, uploads, or parses a local file. That separation matters for sensitive incident response where the sample cannot leave the host. Pair the lookup with a maintained parser running on the analyst's own machine, and keep both the observed bytes and the parser verdict in the case notes so a later reviewer can distinguish a prefix match from a validated file structure.