The File Signatures (Magic Bytes) List is a compact, browser-based reference of twelve source-checked offset-zero prefixes for common formats including JPEG, PNG, GIF, PDF, ZIP, GZIP, 7-Zip, RAR 4, RAR 5, ELF, and SQLite 3. Each row pairs a format name with the exact uppercase hexadecimal bytes that begin the file, ready to copy into a detection rule, an incident-analysis note, or a documentation snippet. Because the table runs entirely in your browser, you can use it as an API alternative: instead of spinning up a libmagic daemon, sending samples to a remote signature service, or wiring up python-magic, you get a quick local lookup that never reads or uploads a file. The reference makes its limits explicit: prefixes are fixed at offset zero, general-purpose magic rules are not reproduced, and a short sequence may collide with unrelated content. The next sections explain what is covered, how to look up a signature step by step, why the table works as a focused alternative to a full API, and the security caveats that determine whether a prefix match is enough to trust an unknown file.
What the table covers
The reference is built around twelve formats that appear constantly in web uploads, content-type checks, and forensic workflows. Images get four rows (JPEG, PNG, both common GIF headers) because GIF has two valid magic strings and a detector that misses one will silently misclassify real files. Documents are represented by PDF, which is the most common binary upload after images. Archives get the largest share: the ZIP local-file header, the GZIP stream signature, the 7-Zip start bytes, and both RAR versions. The ZIP row is intentionally flagged as a container, because the same prefix opens DOCX, XLSX, JAR, EPUB, and other ZIP-based packages. Executables get one row (ELF), and databases get one (SQLite 3). Every entry is fixed at offset zero, so the same hex value works whether you are comparing with a hex viewer, a streaming byte reader, or a one-line script.
| Format | Common extensions | Category | Container note |
|---|---|---|---|
| JPEG | .jpg, .jpeg | Image | — |
| PNG | .png | Image | — |
| GIF (87a) | .gif | Image | — |
| GIF (89a) | .gif | Image | — |
| Document | — | ||
| ZIP | .zip | Container archive | Also DOCX, XLSX, JAR, EPUB |
| GZIP | .gz, .gzip, .tgz | Compressed stream | — |
| 7-Zip | .7z | Archive | — |
| RAR 4 | .rar | Archive | — |
| RAR 5 | .rar | Archive | — |
| ELF | (executable, no fixed extension) | Executable | — |
| SQLite 3 | .sqlite, .sqlite3, .db | Database | — |
Exact offset-zero bytes for each row are listed in the tool itself; copy them directly from the displayed uppercase hex sequence so you do not transcribe a value from memory.
How to look up a file signature step by step
- Open the File Signatures (Magic Bytes) List reference in your browser.
- Search by format name, extension, hexadecimal bytes, or a note such as "container" to narrow the table to the row you need.
- Open the candidate file in a trusted binary viewer and confirm the offset-zero bytes match the space-separated uppercase hexadecimal sequence shown in the table.
- Copy the displayed prefix and paste it into documentation, a tested detection rule, an upload-inspection script, or an incident-analysis note.
- Confirm the full structure with a maintained parser before you trust or process the file, because the prefix is only one signal.
Why this works as an API alternative
A full signature API such as libmagic covers thousands of formats, evaluates indirect offsets, masks, numeric endianness, strings, and nested conditions. The twelve-row reference does not try to replace that. Instead it covers the formats you reach for first when triaging uploads, debugging a content-type mismatch, or writing a quick rule, and it does so without a network round-trip, a server dependency, a runtime binding, or an account. There is no Python install, no magic file download, no pip install python-magic, no separate API key, and no risk that your sample leaves the browser tab. Because the rows are source-checked and protected by tests for exact size and uniqueness, you can paste a prefix into a regression suite with confidence that it is the value you expect. When the format is outside the twelve, or when you need a multi-offset rule, the underlying magic database and the format specification remain the next step.
Container ambiguity and the ZIP row
The ZIP local-file header is the single most misread signature in the list. The same offset-zero prefix begins Office Open XML documents such as DOCX and XLSX, Java JAR archives, EPUB files, and other ZIP-based packages. The reference labels this limitation explicitly rather than pretending the prefix uniquely identifies a download. A robust detector inspects required internal paths, metadata, content types, and relationships while defending against decompression bombs and path traversal. For example, a DOCX file should contain [Content_Types].xml and a word/ directory; a JAR should contain META-INF/MANIFEST.MF. ZIP-based packages are not safe to extract into a writable path without sandboxing, because entries can include ../ segments or nested archives designed to expand. The container prefix is a starting point for triage, not a conclusion.
Limits the reference does not cover
The table is intentionally narrow. It does not include executable subtypes, media codecs, disk images, fonts, mail formats, or every archive variation. It does not reproduce general-purpose libmagic rules, so it cannot evaluate byte sequences at non-zero offsets, indirect offsets, masks, or version-specific trailers. It does not scan uploaded files: no drag-and-drop, no fetch, no server-side parser, no streaming decoder. If you need a full file-type library, link the tool's reference to the upstream magic database and the format specification, and implement production detection there. The twelve rows are starting points for the most common cases and a clean comparison target when you are validating a custom rule.
Why a prefix match is not proof of safety
A matching prefix is one signal, not a verdict. The same short sequence may collide with unrelated content; a malicious file can carry valid magic bytes followed by an invalid or dangerous payload; and many formats allow leading data or multiple valid signatures. A production detector should validate the complete structure with a maintained parser, enforce an allowlist, rename server-side, isolate storage, block active content where appropriate, and serve downloads with safe headers. Antivirus or sandbox analysis may be necessary for higher-risk workflows. Reject truncated inputs even if the first bytes match, because a truncated file will fail any structural check downstream. 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 as part of regression coverage. The browser-based reference makes copying convenient; what you do with the prefix after that determines whether your detector is safe.
How the reference stays accurate
The twelve rows are source-checked against the file command magic database and the SEARCH GCK File Signatures collection, and protected by tests for exact size and uniqueness. Standards and implementations evolve, so critical production rules should still be verified against current upstream documentation, the rule version recorded, and regression samples maintained 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.