A reference that surfaces twelve offset-zero file signatures at once lets developers copy verified prefixes from the File Signatures (Magic Bytes) List without reading any local file, scanning an uploaded sample, or pulling rules from a live database. The reference groups JPEG, PNG, both common GIF headers, PDF, ZIP, GZIP, 7-Zip, RAR 4, RAR 5, ELF, and SQLite 3 into one searchable table where every row lists the format, its extension, the exact hexadecimal prefix, and a short note (such as "container") that flags structural ambiguity. Searching by format name, extension, hex string, or descriptive note finds the row in a single keystroke, and a copy action lifts the uppercase space-separated bytes for a hex viewer, parser test, or detection-rule draft. The tool never opens a file, runs entirely in the browser, and leaves no trace beyond the active tab.
When You Actually Need More Than One Signature
When you are writing an upload validator, hardening an incident-response playbook, or building a small file-type sniffer, the friction is rarely the magic bytes themselves; it is the friction of finding the right prefix quickly. A bulk reference removes that friction by giving every entry one stable offset, one consistent notation, and one place to copy from. The trade-off is scope: the table is intentionally compact, so it serves as a quick lookup rather than a replacement for a full detection database.
Why a Bulk Reference Beats Memorizing a Few Prefixes
Developers rarely need only one signature in isolation. A file-upload pipeline has to recognize images, documents, archives, and possibly executables or SQLite snapshots. A security write-up often quotes two or three prefixes side by side. A parser test suite needs exact bytes for every accepted and rejected sample. Treating each format as a separate lookup wastes time and invites typos in the hex string.
The bulk approach normalizes every entry to space-separated uppercase hexadecimal bytes so the eye moves between rows without reformatting. Notes like "container" and "two valid headers" carry context that does not fit into the bytes themselves, which is what you need when you are distinguishing a ZIP download from a DOCX upload that happens to share the same opening bytes.
Look Up and Copy Multiple Signatures
- Open the File Signatures (Magic Bytes) List in your browser; nothing is uploaded and no account is required.
- Type a search term that matches your task: a format name like "PDF", an extension like ".sqlite", a hex fragment such as "50 4B", or a descriptive note like "container" or "archive".
- Read the matching row for the format name, extension, exact offset-zero hex sequence, and any note about container overlap, version variants, or ambiguity.
- Repeat the search for every format you need so the resulting set of prefixes stays consistent in notation and ordering.
- Open each candidate file in a trusted binary viewer or hex dump and align the offset-zero bytes against the rows you collected.
- Copy each displayed hex string with the in-row copy action, then paste them into documentation, an upload-validation rule, a parser test fixture, or an incident-response note.
- Before processing or trusting any file, validate its full structure with a maintained parser, enforce size limits and an allowlist, and treat every prefix match as one signal rather than proof.
The Twelve Signatures and the Notes Attached to Them
The following table summarizes every row currently in the reference. Hex values are written as space-separated uppercase bytes for direct comparison with a hex viewer.
| Format | Extension | Offset-zero hex | Note |
|---|---|---|---|
| JPEG | .jpg / .jpeg | FF D8 FF | Image; multiple JFIF/EXIF variants follow |
| PNG | .png | 89 50 4E 47 0D 0A 1A 0A | Image; fixed signature, then IHDR chunk |
| GIF87a | .gif | 47 49 46 38 37 61 | Image; legacy header |
| GIF89a | .gif | 47 49 46 38 39 61 | Image; animated and extension header |
| 25 50 44 46 | Document; %PDF, version follows | ||
| ZIP | .zip | 50 4B 03 04 | Container; also DOCX, XLSX, JAR, EPUB |
| GZIP | .gz | 1F 8B | Archive; compressed payload follows |
| 7-Zip | .7z | 37 7A BC AF 27 1C | Archive; fixed signature |
| RAR 4 | .rar | 52 61 72 21 1A 07 | Archive; legacy version |
| RAR 5 | .rar | 52 61 72 21 1A 07 01 00 | Archive; current version |
| ELF | (none / executable) | 7F 45 4C 46 | Executable; class follows at offset 4 |
| SQLite 3 | .sqlite / .db | 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 | Database; "SQLite format 3" |
The table does not claim to cover every format. It does not include media codecs, disk images, fonts, mail formats, or every archive variant. For anything outside this set, consult the linked file command magic database and the format specification.
Container Formats Create Real Ambiguity
The ZIP local-file header at offset zero, 50 4B 03 04, is one of the most misused prefixes in detection code. It matches plain ZIP archives, but it also matches Office Open XML documents (DOCX, XLSX, PPTX), Java JAR files, EPUB ebooks, Android APK packages, and other ZIP-based bundles. Recognizing the container tells you how to parse the file, not which application format it represents. A robust detector inspects required internal paths such as [Content_Types].xml for Office documents, META-INF/MANIFEST.MF for JAR, and mimetype for EPUB, and checks content-type metadata before deciding what to do with the upload.
The same caveat applies to executable prefixes. ELF begins with 7F 45 4C 46, but the same first four bytes appear in many Linux binaries regardless of architecture, and a malicious file can copy the bytes while carrying unrelated content later. Magic bytes are a structural pointer; they are not a signature of safety or intent.
Validating Files Beyond the Magic-Bytes Check
A prefix match is a start, not a verdict. Production detection should pair the bulk lookup with several controls.
First, validate the full structure with a maintained parser that matches the candidate format - libzip for ZIP, libpng for PNG, the SQLite C library for SQLite databases. Reject truncated inputs even when the first bytes line up, because parsers fail fast on missing chunks or central directories.
Second, enforce an allowlist of expected extensions, MIME types, and size ceilings for every upload path. Decompression bombs and oversized payloads are not detected by magic bytes at all; they need explicit limits.
Third, isolate storage, rename files server-side, block active content where appropriate, and serve downloads with safe headers. Antivirus or sandbox analysis may be necessary for higher-risk workflows. Record both the observed bytes and the parser verdict so later reviewers can distinguish a prefix match from a fully validated file structure.
Fourth, keep detection libraries and decoders patched, and test malformed, polyglot, oversized, and nested samples. Standards and implementations can evolve, which is why critical production rules should be verified against the current upstream documentation in the SEARCH GCK File Signatures database, the file command magic repository, and the relevant format specification.
Bulk Reference vs a Full Detection Database
The following table compares the in-browser bulk reference with a general-purpose detection rule library such as the file command magic database. It is a structural comparison, not a verdict on either approach.
| Property | File Signatures (Magic Bytes) List | General-purpose libmagic rules |
|---|---|---|
| Number of entries | Twelve offset-zero prefixes | Thousands, spanning many formats |
| Offset handling | Fixed at offset zero | Any offset, indirect offsets, masks, nested conditions |
| Notation | Space-separated uppercase hex | Mixed numeric, string, and regex expressions |
| Local-file access | None - reference only | Reads file bytes directly |
| Scope | Common images, documents, archives, ELF, SQLite | Includes media codecs, fonts, disk images, mail formats |
| Best use | Quick lookup, copy a verified prefix, teach the concept | Production detection in a controlled pipeline |
For a single upload validator handling five common formats, the in-browser reference is enough to draft a rule list, copy exact bytes, and reason about container overlap. For production detection at scale, the file command rules and similar libraries carry the heavier lifting because they evaluate byte sequences at any offset, check numeric endianness, and combine multiple conditions. Treating the bulk reference as a teaching and copy aid - and a quick sanity check - matches the scope it is built for.
For developers who want to see the same twelve prefixes from a different angle, the twelve verified prefixes guide walks through the verified-prefix perspective, and the twelve common prefixes guide shows how each format fits into a typical detection rule.