Magic-Byte File Identification: How Browsers Detect Binary Formats Without Extensions
An engineering deep dive into hexadecimal magic numbers, OLE2 Compound Document streams, ZIP container disambiguation, and how ViewAnyFile.app identifies misnamed or extensionless files in local RAM.
Quick Answer: Operating systems rely on filename suffixes (like .pdf or .jpg) to choose which program opens a file, which fails whenever an extension is stripped or renamed. ViewAnyFile.app inspects the raw hexadecimal header bytes ("magic numbers") at offset 0x00—and secondary container structures like ZIP central directories and OLE2 sector tables—directly inside a browser ArrayBuffer to identify the true binary specification before launching a parser.
Why Filename Extensions Are Fundamentally Unreliable
Since the MS-DOS era, desktop operating systems have used the characters after the final period in a filename as a lookup key in the system registry. If you rename quarterly-report.pdf to quarterly-report.jpg, Windows and macOS will dutifully pass the file to an image viewer, which immediately crashes with a "corrupt or unsupported image" error. In real-world engineering, legal discovery, and IT helpdesk workflows, files frequently arrive with broken or missing extensions:
- Email Gateway Quarantines & Winmail.dat: Corporate SMTP filters and legacy Exchange servers often strip extensions or rename attachments to generic
.dator.binblobs. - Mobile Messaging & Cloud Sync: Files exported from iOS share sheets, WhatsApp backups, or S3 object buckets without a
Content-Dispositionfilename arrive as extensionless UUIDs. - Renamed Container Formats: Dozens of distinct file formats—including
.docx,.xlsx,.pptx,.epub,.jar,.apk, and SketchUp.rbz—are actually standard PKZIP archives under the hood.
Stage 1: Hexadecimal Magic Bytes at Offset 0x00
Nearly every binary file specification designed over the past four decades reserves the first 2 to 16 bytes of the file stream as a deterministic signature—known in systems programming as magic bytes. When you drop a file into ViewAnyFile.app, we do not read the entire multi-hundred-megabyte payload just to identify it. Instead, we call file.slice(0, 512).arrayBuffer() via the W3C File API, reading only the first 512 bytes into a Uint8Array in sub-millisecond time.
| Format | Byte Offset | Hexadecimal Signature | ASCII Representation |
|---|---|---|---|
PDF Document (.pdf) |
0x00 (0) |
25 50 44 46 2D |
%PDF- |
PNG Bitmap (.png) |
0x00 (0) |
89 50 4E 47 0D 0A 1A 0A |
.PNG.... |
JPEG Image (.jpg) |
0x00 (0) |
FF D8 FF |
SOI + APP0/Exif Marker |
Photoshop (.psd) |
0x00 (0) |
38 42 50 53 |
8BPS |
AutoCAD (.dwg) |
0x00 (0) |
41 43 31 30 33 32 |
AC1032 (R2018+) |
glTF Binary 3D (.glb) |
0x00 (0) |
67 6C 54 46 |
glTF |
Blender Scene (.blend) |
0x00 (0) |
42 4C 45 4E 44 45 52 |
BLENDER |
SQLite 3 DB (.sqlite) |
0x00 (0) |
53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 |
SQLite format 3\0 |
DICOM Medical (.dcm) |
0x80 (128) |
44 49 43 4D |
DICM (after 128B preamble) |
Stage 2: Non-Zero Offset Signatures (DICOM, ISO BMFF & TAR)
Not all specifications place their magic number at byte zero. A clinical DICOM (.dcm) medical scan begins with a 128-byte null preamble (0x00 through 0x7F) designed for backward compatibility with legacy hospital image viewers; the actual 44 49 43 4D (DICM) signature appears at byte offset 128 (0x80). Similarly, Apple HEIC (.heic) and MP4 (.mp4) containers follow the ISO Base Media File Format (ISO/IEC 14496-12), where bytes 0..3 encode a 32-bit big-endian box length, bytes 4..7 spell ftyp (66 74 79 70), and bytes 8..11 declare the specific brand—such as heic, mif1, or isom. Our signature analyzer inspects these exact structural offsets rather than relying on naive prefix matching.
Stage 3: Disambiguating ZIP-Based & OLE2 Compound Containers
Two of the most widespread container architectures in computing share identical magic bytes across dozens of incompatible file formats:
- PKZIP Containers (
50 4B 03 04): Microsoft Office OpenXML (.docx,.xlsx,.pptx), OpenDocument (.odt,.ods), IDPF eBooks (.epub), and 3D Manufacturing (.3mf) all start withPK\x03\x04. When ViewAnyFile encounters a PKZIP header on an unknown file, our inspector reads the local file header filenames inside the ZIP stream:- If it contains
word/document.xml→ route to the DOCX Document Renderer. - If it contains
xl/workbook.xml→ route to the SheetJS Spreadsheet Grid. - If it contains
ppt/presentation.xml→ route to the PPTX Slide Engine. - If it contains
META-INF/container.xmland an uncompressedmimetypeofapplication/epub+zip→ route to the EPUB Reflowable Reader.
- If it contains
- OLE2 Compound File Binary Format (
D0 CF 11 E0 A1 B1 1A E1): Legacy Microsoft Word (.doc), Excel (.xls), PowerPoint (.ppt), Outlook messages (.msg), SolidWorks parts, and InPage Urdu (.inp) documents all use Microsoft's FAT-like Compound Document container. By inspecting the UTF-16LE directory stream names inside the OLE2 allocation table (such as__substg1.0_for Outlook.msgvs.InPage100for Urdu.inp), ViewAnyFile routes each binary to its specialized decoder.
Stage 4: Heuristic AST & Text Encoding Analysis for Plain-Text Formats
Source code, configuration manifests, and tabular datasets (.json, .csv, .xml, .svg, .ifc, .step, .obj) do not have binary magic numbers because they are UTF-8 or ASCII text streams. For text streams, our analyzer first checks for Unicode Byte Order Marks (EF BB BF for UTF-8, FF FE for UTF-16LE), verifies that zero null bytes (0x00) exist in the first 4 KB, and runs lightweight lexical probes—detecting ISO-10303-21; headers for STEP CAD and IFC BIM models, <svg root namespaces for vector graphics, or RFC 5322 Received: / MIME-Version: headers for EML emails.