A file signatures list alternative is a compact reference of twelve source-checked magic byte prefixes covering JPEG, PNG, both common GIF headers, PDF, ZIP, GZIP, 7-Zip, RAR 4, RAR 5, ELF, and SQLite 3. Searchable by format, extension, hex bytes, or a note such as container, the table returns space-separated uppercase hex bytes ready to paste into a hex viewer comparison, an upload inspection rule, or an incident-analysis note. Every search and copy runs locally in the current tab — no account, no upload, no dependency — so the reference is a safer first stop than a hosted lookup service that expects you to submit a sample just to read its first four bytes. Values are fixed at offset zero, which keeps the comparison rule simple and the table reviewable by anyone reading the code. The reference deliberately stops at offset zero because the goal is fast, transparent byte comparison, not general-purpose format inference.
Why Developers Look for an Alternative File Signature List
FileSignatures.net, a long-running public database of file signatures, has displayed a maintenance notice for an extended period, leaving developers who relied on its quick search for magic bytes without their first stop. That gap has pushed many engineers toward alternatives that emphasise a smaller, verifiable set of prefixes over comprehensive enumeration. A focused list answers a different question than a general identification tool: instead of asking "what is this file?" by uploading a sample, you want a clean reference that lets you compare the bytes you already see against a known prefix.
Browser-only execution is another reason to keep an alternative handy. When you are debugging a parsing bug on an isolated workstation, triaging a suspicious upload on a locked-down host, or working through an incident on a network that blocks third-party lookups, a reference that runs in a single tab without a server round-trip removes friction that an API-backed service cannot avoid. Copying the exact hex string into a runbook or detection rule is also faster than transcribing it from a screenshot or a hosted database with overlapping columns.
Adoption of libmagic-style detection in production pipelines has grown alongside these constraints. According to the file command magic database maintained on GitHub, general-purpose rules can evaluate byte sequences at other offsets, indirect offsets, masks, numeric endianness, strings, and nested conditions. That power is useful in production, but it is also why many teams keep a smaller, fixed-offset reference available for everyday comparisons and onboarding material. The alternative is not a replacement for a full magic database — it is a focused complement.
What the Browser-Based File Signatures List Covers
The File Signatures (Magic Bytes) List stores twelve source-checked offset-zero byte prefixes with unique identifiers and format-plus-hex pairs, normalised across format names, extensions, hex bytes, and short notes. Every entry is fixed at offset zero so the comparison rule stays simple and the table stays reviewable by anyone reading the code. The tool does not reproduce the offset-aware, masked, or indirect-offset rules from a general-purpose database, and it does not scan uploaded files; it is a searchable reference, not an identifier.
The twelve rows cover a deliberately small set of formats that show up constantly in web uploads, log analysis, and incident triage:
| Format | Common extension | Category | Note |
|---|---|---|---|
| JPEG | jpg, jpeg | Image | Offset-zero prefix only |
| PNG | png | Image | Offset-zero prefix only |
| GIF (87a) | gif | Image | Older GIF variant header |
| GIF (89a) | gif | Image | Newer GIF variant header |
| Document | Document format header | ||
| ZIP | zip | Archive container | Same prefix appears in DOCX, XLSX, JAR, EPUB |
| GZIP | gz, gzip | Archive | Single offset-zero prefix |
| 7-Zip | 7z | Archive | 7z container header |
| RAR (version 4) | rar | Archive | Older RAR format header |
| RAR (version 5) | rar | Archive | Current RAR format header |
| ELF | (no fixed extension) | Executable | Linux, BSD, and Unix binaries |
| SQLite 3 | sqlite, db, sqlite3 | Database | Database container format |
Values are presented as space-separated uppercase hexadecimal bytes, which means you can paste them straight into a hex viewer, a parser comparison, an upload inspection rule, or an incident-analysis note without converting from another notation. Because the rows are source-checked and protected by tests for exact size and uniqueness, you can trust that the bytes you copy match the bytes in the table — but standards and implementations can evolve, so verify critical production rules against current upstream documentation and record the rule version in your runbook.
How to Look Up Magic Bytes Using the Alternative
- Search the table. Open the File Signatures (Magic Bytes) List in your browser and type a query in the search field. Use a format name (PDF), an extension (zip), a hex prefix (50 4B), or a short note such as container. The search runs across format names, extensions, hex bytes, and notes, so any of those will surface the right row.
- Compare the offset-zero prefix with a trusted binary view. Open the suspect file in a hex editor or binary viewer of your choice and look at the first few bytes. The space-separated uppercase hex in the table should match the bytes you see at the start of the file. If the table says the prefix starts at offset zero, do not start the comparison at offset 4 or 16; the bytes must line up at the very beginning of the file.
- Copy the prefix for documentation or a tested detection rule. Use the copy control next to the row to place the exact hex string into your clipboard. Paste it into a detection rule, an upload filter, a runbook, or a code comment. Because the tool never reads your local file, no bytes from the suspect file leave your machine during this step.
- Confirm the full structure with a maintained parser before trusting or processing the file. A matching prefix is one signal, not proof. Run a maintained parser or decoder against the whole file to validate the structure, then enforce allowlists, size limits, and context-specific security controls before you act on the file's contents.
That last step is the one most often skipped. The tool is built around the principle that magic bytes alone should never authorise an upload: validate the complete file, enforce an allowlist, rename server-side, isolate storage, block active content where appropriate, and serve downloads with safe headers. Antivirus or sandbox analysis may still be necessary for higher-risk workflows. Reject truncated inputs even if the first bytes match, because a prefix tells you nothing about the rest of the file.
The Container Format Trap: Why ZIP Detection Alone Fails
One of the most common mistakes when rolling a file-type detection rule out of a signature list is treating a single prefix as a complete answer. The ZIP local-file header, for example, also appears at the start of Office Open XML documents such as DOCX and XLSX, Java JAR archives, EPUB files, and many other packaged formats. Identifying the container does not identify the contained application format, and the reference table explicitly labels this limitation instead of claiming that the ZIP prefix uniquely means a downloadable archive.
A robust detector must inspect the required internal paths, metadata, relationships, and content types of the package to distinguish a DOCX from a JAR or an EPUB. The same logic applies in the other direction: if you only ever check the prefix, a malicious file can copy expected bytes while carrying invalid or dangerous payload data later in the file. Magic bytes are useful, but they are not a substitute for structural parsing. Defence in depth is the rule — keep detection libraries and decoders patched, test malformed, polyglot, oversized, and nested samples, and treat the prefix match as the start of a verification chain rather than the end of one.
Container formats also expose a more subtle engineering hazard. A short prefix can collide with unrelated content by accident, and ZIP packages in particular can hide decompression bombs and path traversal payloads behind a perfectly normal prefix. Avoid exposing parser errors, filesystem paths, or internal rules to untrusted users, and never accept an upload solely because the first four bytes looked right. If you need a broader view than twelve offset-zero entries can give you, the maintained public database at SEARCH GCK File Signatures is a useful next stop for verification, and the upstream file magic directory documents the offset-aware rules that production detectors tend to inherit.
When a Reference List Is Not Enough: Detection Limits to Respect
Even a source-checked list has limits. The twelve offset-zero entries do not include executable subtypes, media codecs, disk images, fonts, mail formats, or every archive variation, because the reference is meant to stay compact and reviewable rather than exhaustive. Some formats allow leading data, multiple valid signatures, or version-specific headers, so a single prefix per row is a working assumption rather than a universal rule. A short prefix can collide with unrelated content, and the contract behind the table explicitly warns against treating any prefix match as proof of type or safety.
Production detection almost always needs more than this. General-purpose libmagic rules can evaluate byte sequences at other offsets, indirect offsets, masks, numeric endianness, strings, and nested conditions — none of which this tool reproduces. Treat the list as one signal alongside structural parsing, size limits, trusted decoders, and context-specific security controls. When you implement production detection beyond these common examples, consult the linked primary database and the format specification, 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 record is what turns a quick lookup into an audit trail, and it is also what keeps the alternative useful as a focused complement to a heavier detection stack rather than a fragile replacement for one.