File magic numbers are short, fixed byte sequences at the very beginning of a file that identify its format more reliably than a filename extension. The pattern usually occupies the first few bytes at offset zero, so a detector can read the prefix without scanning the entire file and recognize the format before any deeper parsing begins. A JPEG, for example, almost always starts with the bytes FF D8 FF, while a portable document starts with the bytes 25 50 44 46, the ASCII string %PDF. Because the value sits at a known position, magic bytes are widely used by command-line tools, upload validators, file managers, antivirus engines, and incident-response pipelines as the first quick check on an unknown binary. The tradeoff is that a prefix match is one signal rather than proof: a malicious file can copy expected bytes, a single prefix may match several container formats, and the prefix alone cannot guarantee safety or full structural validity. A searchable reference of common signatures, paired with a maintained parser, is the practical starting point for almost any detection task.
How Offset-Zero Prefixes Identify a Format
A file magic number is the first signal a detector reads, and it works because the position is predictable. Most binary formats reserve the first few bytes for a fixed header that includes either printable identifiers or constants the format specification defines. PNG files always begin with the eight bytes 89 50 4E 47 0D 0A 1A 0A, ELF executables start with 7F 45 4C 46, and SQLite databases lead with the literal ASCII string SQLite format 3 followed by a null byte. Reading only those bytes is cheap, side-effect-free, and language-agnostic, which is why upload pipelines, mail gateways, and reverse-engineering tools all reach for the prefix first.
The offset matters. The signatures listed in a compact reference are checked at exactly offset zero, so a detector only has to read a fixed number of bytes from the start of the file. General-purpose tools like libmagic go further: they evaluate byte sequences at other offsets, indirect offsets, masks, numeric endianness, strings, and nested conditions. That broader scope catches formats whose identity sits deeper in the header, but it also demands a real rule engine. A plain offset-zero prefix table is the right scope for a quick first check, a teaching reference, or a detection rule that the reader wants to copy and paste directly.
A prefix is only one signal. The same byte sequence can appear in unrelated content, a malformed file may start correctly and then diverge, and a malicious file can copy the expected bytes while carrying a different payload later. Production detection always combines the prefix with structural parsing, size limits, trusted decoders, and context-specific security controls rather than relying on the prefix alone.
The Twelve Common Signatures in One Place
A compact, source-checked list of twelve formats covers most of the binaries a developer encounters in a single workday: images, documents, archives, executables, and embedded databases. The twelve rows in the File Signatures (Magic Bytes) List reference represent JPEG, PNG, both GIF headers (87a and 89a), PDF, ZIP, GZIP, 7-Zip, RAR 4, RAR 5, ELF, and SQLite 3. Values are stored as space-separated uppercase hexadecimal bytes so they can be compared directly with a hex viewer, a binary parser, an upload inspection rule, or an incident-analysis note without conversion from another notation.
The reference table is short on purpose. It does not include executable subtypes, media codecs, disk images, fonts, mail formats, or every archive variation. Those are covered by larger maintained databases; this list is the small, exact-prefix subset a person can verify by eye during incident response or while writing a detection rule.
| Format | Common Extensions | Offset-Zero Hex Prefix | Note |
|---|---|---|---|
| JPEG | .jpg, .jpeg | FF D8 FF | Image, often followed by EXIF or JFIF marker |
| PNG | .png | 89 50 4E 47 0D 0A 1A 0A | Image, fixed eight-byte header |
| GIF87a | .gif | 47 49 46 38 37 61 | Image, ASCII string GIF87a |
| GIF89a | .gif | 47 49 46 38 39 61 | Image, ASCII string GIF89a |
| 25 50 44 46 | Document, ASCII string %PDF | ||
| ZIP | .zip, .docx, .xlsx, .jar, .epub | 50 4B 03 04 | Container, also DOCX, XLSX, JAR, EPUB |
| GZIP | .gz, .gzip, .tgz | 1F 8B | Compressed stream |
| 7-Zip | .7z | 37 7A BC AF 27 1C | Archive |
| RAR 4 | .rar | 52 61 72 21 1A 07 00 | Archive, version 4 |
| RAR 5 | .rar | 52 61 72 21 1A 07 01 00 | Archive, version 5 |
| ELF | (none, executable) | 7F 45 4C 46 | Executable, ASCII string .ELF |
| SQLite 3 | .sqlite, .sqlite3, .db | 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 | Database, ASCII string SQLite format 3 plus null |
The values above are the canonical offset-zero prefixes defined by each format's public specification and recorded in the file command magic database. They are presented in uppercase, space-separated hexadecimal so they can be pasted directly into a rule, a notebook entry, or a hex comparison without further conversion.
How to Look Up and Verify a Magic Number
The fastest path from an unknown file to a known prefix is a single searchable table. The verified workflow below uses the File Signatures (Magic Bytes) List as the lookup step and a maintained parser as the validation step.
- Search by format, extension, bytes, or a note such as container. Type zip, container, or the hex bytes 50 4B 03 04 into the search box to narrow the twelve rows to the format you need. The search is normalized across format name, extension, hex string, and the descriptive note so a partial query still matches.
- Compare the offset-zero hexadecimal sequence with a trusted binary view. Open the file in a hex viewer or read the first few bytes with your language's binary reader, then line the bytes up against the prefix from the table. The reference displays uppercase hex with single-byte spacing so the comparison stays literal.
- Copy the prefix for documentation or a tested detection rule. Use the copy action in the tool to place the exact bytes into a detection rule, a wiki page, or an incident note. Copying from the reference avoids transcription errors and keeps the casing and byte order identical to the rule engine you will compare against.
- Confirm the full structure with a maintained parser before trusting or processing the file. Match the prefix, then validate the complete file with a maintained parser, enforce an allowlist, and apply context-specific security controls. The reference is a starting point, not an authorization step.
Container Formats Create Real Ambiguity
A prefix can identify a container, but not necessarily the application format inside it. The ZIP local-file header, 50 4B 03 04, is the canonical example. It appears in plain ZIP archives, but it also appears at offset zero of Office Open XML documents such as DOCX and XLSX, Java JAR archives, EPUB ebooks, and many other package formats. A detector that stops at the prefix would happily label a malicious .docx as a .zip download, or vice versa, and the user would have no way to tell the difference from the bytes alone.
A robust detector must open the container and inspect required internal paths, metadata, relationships, and content types. A DOCX is expected to contain word/document.xml and a [Content_Types].xml entry; an EPUB carries mimetype with the contents application/epub+zip as the first entry; a JAR has META-INF/MANIFEST.MF. The table in the reference explicitly labels this limitation instead of claiming that 50 4B 03 04 uniquely means a .zip download. Treating container detection as anything more than a first pass is the difference between a useful filter and a vulnerability.
Container formats also carry their own risks. Decompression bombs inflate a tiny archive into gigabytes of output, path traversal attacks step outside the intended extraction directory, and parser bugs turn malformed entries into arbitrary code execution. Allowlisting expected internal files, enforcing per-file and total size limits, isolating extraction paths, and running antivirus analysis on high-risk workflows are all part of the same defense.
When a Prefix Match Is Not Enough
A matching prefix never proves a file is safe. The byte pattern at the start of a file can be copied by a malicious actor who then appends or interleaves a different payload, so a sniff rule that accepts a payload purely on prefix strength is accepting untrusted content. Validating the complete structure with a maintained parser, enforcing an allowlist, renaming uploads server-side, isolating storage, blocking active content where appropriate, and serving downloads with safe headers are all part of the same control set. Antivirus or sandbox analysis may be necessary for higher-risk workflows.
Truncated inputs are another common false positive. A one-kilobyte file that begins with FF D8 FF is not a usable JPEG, no matter how clean the prefix looks. Detectors should reject truncated files explicitly rather than rely on parser errors that bubble up to the user. Avoid exposing parser errors, filesystem paths, or internal rules to untrusted users, and keep detection libraries and decoders patched. Test malformed, polyglot, oversized, and nested samples during development and on every rule update.
The reference runs entirely in the browser and does not request or read a local file. Searches and copies stay in the current tab, no account is required, and no dependency is added. That makes it safe to consult during incident response or while writing detection logic without accidentally exfiltrating the file under analysis.
Beyond the Twelve: Where to Go Next
Once a developer needs more than offset-zero prefixes, the next two resources are the maintained file command magic database and a community-maintained signature table. The file command magic database is the canonical source behind the libmagic library used by the Unix file command, and it evaluates byte sequences at indirect offsets, masks, numeric endianness, strings, and nested conditions. The SEARCH GCK File Signatures table is searchable by extension and description and covers many more formats. Both should be consulted when implementing production detection beyond the common examples in the twelve-row reference.
The entries in the twelve-row reference are protected by tests for exact size and uniqueness, but standards and implementations can evolve. Verify critical production rules against current upstream documentation, record the rule version, and maintain regression samples that include both accepted formats and adversarial near-matches. Record both the observed bytes and the parser verdict so later reviewers can distinguish a prefix match from a validated file structure. That audit trail is what separates a detection rule you can defend in a postmortem from one that quietly accepts an attacker's hand-crafted prefix.