File Signatures List: Command Line vs Online

Command-line tools can inspect local file bytes, while the File Signatures (Magic Bytes) List is a browser-based reference for searching and copying twelve fixed, offset-zero prefixes.

The practical difference is that a command-line workflow reads a specific local file, while the online list helps you find a known prefix to compare. A successful lookup or classifier result is evidence, not proof that a file is complete, safe, or exclusively one format.

What command-line and online lookup each do

Choose according to the question you need answered: “Which bytes begin this local file?” points to command-line tools; “What is the documented prefix for this format?” points to an online list. These are different jobs, and an online lookup table is not an upload scanner.

Approach	What it does	Best fit	Main boundary
Command-line classifier	Reads a specific local file and applies magic rules	Broader pattern-based classification	A label is not structural validation or a safety verdict
Raw-byte command	Displays the file’s leading bytes	Comparing a candidate signature	Does not identify a format by itself
Online File Signatures List	Searches twelve fixed, offset-zero prefixes and copies their byte values	Finding a known prefix for documentation or rule drafting	Does not request, read, upload, or scan a local file
Maintained parser	Validates the required internal structure	Making a trust or processing decision	Needs format-specific parsing and separate security controls

The Unix file command uses the broader magic-rule model represented in the file command magic database. Those rules can evaluate byte sequences at other offsets, indirect offsets, masks, numeric endianness, strings, and nested conditions. The online list fixes every entry at offset zero for a clear, testable scope and does not reproduce that rule system. It also omits executable subtypes, media codecs, disk images, fonts, mail formats, and every archive variation.

Inspect a local file at the command line

1. Choose the exact candidate. Pass the file path directly to each command, quoting the path if it contains spaces. Treat the filename extension as a clue rather than evidence of the format.
2. Read the leading bytes. On Unix-like systems with xxd installed, run xxd -l 16 sample.bin. A common alternative is od -An -tx1 -N 16 sample.bin. Their output layouts differ, so compare the byte values rather than the spacing, case, address column, or ASCII column.
3. Run a broader classifier. Use file sample.bin or file --brief sample.bin when you want the installed magic rules to suggest a type. The result can depend on the tool version and magic database available on the machine.
4. Compare the expected prefix. Check the exact values and their position rather than relying on a visual resemblance. For example, the ZIP local-file header is 50 4B 03 04, but that value establishes a ZIP-style container, not the particular application format stored inside it.
5. Validate the complete structure. Pass the candidate to a maintained, format-specific parser before trusting or processing it. Record the observed bytes separately from the parser’s verdict so a prefix match is never mistaken for a validated file.

This shell workflow has more reach than a static lookup list because it inspects actual local data and can use broader rules. It still has the same trust boundary: a hex view establishes what is present, and a parser establishes whether the required structure is valid.

When the online list is the better choice

The list covers JPEG, PNG, GIF87a, GIF89a, PDF, ZIP, GZIP, 7-Zip, RAR 4, RAR 5, ELF, and SQLite 3. That produces twelve source-checked entries, including both common GIF headers. Every entry is fixed at offset zero, and values appear as space-separated uppercase hexadecimal bytes so they can be compared directly with a hex viewer, parser rule, or incident-analysis note.

Use it when you need to search by format, extension, bytes, or a note such as “container”; copy a known prefix into documentation or a tested detection rule; or compare a trusted binary view without moving the file anywhere. It runs entirely in the browser, never requests or reads a local file, and keeps searches and copies in the current tab without an account or added dependency. It is not a general file scanner, so for broader coverage consult the SEARCH GCK File Signatures database and the relevant format specification.

Copy and validate a signature in four steps

1. Search for the format. Enter a format name, extension, hexadecimal value, or note such as “container.” Searching by extension narrows the possibilities but does not authenticate the extension.
2. Compare at offset zero. Open the candidate in a trusted binary view and compare its first bytes with the displayed signature. Account for differences in hexadecimal notation, and do not treat a match elsewhere in the file as equivalent to the fixed offset-zero entry.
3. Copy the exact prefix. Use the displayed uppercase, space-separated bytes for documentation or a tested detection rule. Preserve the rule source and version so a later reviewer can reproduce the comparison.
4. Confirm the full structure. Validate the complete file with a maintained parser before trusting or processing it. Record both the observed bytes and the parser verdict, rather than reducing the review to one “magic bytes matched” result.

Some formats permit leading data, multiple valid signatures, or version-specific headers. A short prefix may also collide with unrelated content, so failure to match one fixed entry does not automatically identify the file, just as a successful match does not validate it.

Why one prefix can hide several formats

The ZIP local-file header can appear in Office Open XML documents such as DOCX and XLSX, Java JAR archives, EPUB files, and other packages. The list explicitly labels this ambiguity: 50 4B 03 04 identifies a ZIP-based container but does not distinguish the contained application format.

A robust container detector must inspect required internal paths, metadata, relationships, and content types. It should also defend against decompression bombs and path traversal. Even a valid container structure does not establish safety: a malicious file can copy the expected bytes while placing invalid or dangerous payload data later in the file.

Controls for a production file check

The online list does not validate uploads, enforce security policy, or authorize a file. A production implementation should add controls appropriate to the risk:

• Use an allowlist. Combine the validated parser result with the expected format and enforce size limits rather than accepting a file because its extension or prefix matches.
• Handle hostile inputs. Reject truncated or malformed files, maintain patched decoders, and regression-test polyglot, oversized, nested, and adversarial near-match samples.
• Control storage and delivery. Rename files server-side according to a validated type, isolate stored uploads, block active content where appropriate, and serve downloads with safe headers.
• Escalate higher-risk analysis. Antivirus or sandbox analysis may be necessary when a prefix match is insufficient for the workflow.
• Protect internal details. Avoid exposing parser errors, filesystem paths, or detection rules to untrusted users.

Never authorize an upload solely because its prefix matches a list. A magic-byte match is one signal alongside structural parsing, resource limits, trusted decoders, and context-specific security controls.

Choose the route that matches the task

Use the appropriate combination for the outcome you need:

• Inspect an unknown local file: use xxd or od for raw bytes, the file command for broader classification, and a maintained parser for a verdict.
• Look up a known format: use the online File Signatures List to search and copy a documented offset-zero prefix without reading the file.
• Build production detection: combine a source-checked prefix with full structural validation, an allowlist, resource limits, and appropriate security controls.

In short, the command line answers “What do this local file’s bytes and broader rules indicate?” The online list answers “Which known prefix should I compare?” Neither replaces complete validation.