File Analyzer

Why file extensions alone cannot be trusted

A file extension is nothing more than a naming convention — a suffix attached to a filename that operating systems and applications use as a hint about what format the file is in. Nothing prevents anyone from renaming malware.exe to invoice.pdf, and nothing in the extension itself reveals the mistake. File systems on every major platform treat extensions as metadata, not as a property of the file's actual binary content.

This matters more than most people realize. When you download an attachment, receive a file from an untrusted source, or find an old file on a backup drive with an ambiguous name, the extension might be wrong, outdated, or deliberately misleading. A PNG that was accidentally saved with a .jpg extension will still display fine in most browsers — but an image editor that strictly validates the header before processing will either refuse to open it or mishandle the file. A text file that got renamed with a binary extension will confuse text editors. And a genuinely malicious file disguised as a document is a real security concern in enterprise environments.

The correct way to determine what a file actually is relies on reading the file's content directly — specifically its magic bytes, its MIME type, and for certain formats its embedded metadata. The File Analyzer performs all three levels of inspection in your browser without sending any data to a server.

Magic numbers and file signatures

Every widely-used binary file format reserves the first few bytes of the file for a fixed sequence called a magic number or file signature. These bytes are placed there by the application that creates the file, and they serve as a reliable fingerprint for the format. The term "magic number" comes from Unix tradition — the Unix file command has used this technique to identify file types since the 1970s, consulting a database of known signatures to report what a file actually is rather than guessing from its name.

The magic bytes occupy as few as 2 bytes (for some older formats) and as many as 16 or more for formats that need to encode additional format version information in the header. The File Analyzer reads the first 512 bytes of any dropped file — enough to cover the signatures of every common format — and matches them against a table of known signatures to determine the true type.

One important subtlety: the ZIP signature (50 4B 03 04) is shared by many formats. Microsoft Office Open XML formats — DOCX, XLSX, PPTX — are internally ZIP archives. So are Java JAR files, Android APK files, Python wheel packages, and browser extensions. If you drop a DOCX file on the analyzer, the magic bytes alone report "application/zip". To distinguish these formats, the analyzer goes further: it inspects the ZIP's internal file list to check whether characteristic files are present (such as word/document.xml for DOCX or META-INF/MANIFEST.MF for JAR).

If you spot a file where the magic bytes indicate a Windows PE executable but the extension says .jpg, you have found a disguised binary — a common malware delivery technique. The hex viewer in the analyzer makes this visible immediately without needing any specialist forensics tools.

MIME types: the web's file type system

MIME stands for Multipurpose Internet Mail Extensions, originally designed for email attachments and later adopted universally for HTTP. A MIME type is a two-part identifier in the format type/subtype — for example image/jpeg, application/pdf, or text/csv. The type part indicates the broad category (text, image, audio, video, application) and the subtype identifies the specific format within that category.

When your browser reports a file's MIME type, it typically derives this from the file extension using the operating system's MIME type registry. This is fast but unreliable for the same reason extensions are unreliable — the registry mapping is just a lookup table, not an inspection of actual content. The File Analyzer reports both: the browser-reported MIME type (from the extension) and the true MIME type detected from magic bytes. When these two disagree, that discrepancy is itself a meaningful signal.

MIME types are used by servers to set the Content-Type HTTP header, telling browsers how to handle a downloaded file. A server that sends a JavaScript file with Content-Type: text/plain will cause browsers to refuse to execute it as a script. Upload endpoints frequently check MIME type to decide whether to accept a file — which is why knowing the true MIME type, not just what the extension implies, is important for debugging failed uploads.

What it inspects

The browser's File API gives JavaScript access to a file's bytes without any network request. Combined with SubtleCrypto for hashing and a built-in EXIF parser, the tool can tell you more about a file than the operating system's "Get Info" dialog.

EXIF metadata: what images remember

EXIF stands for Exchangeable Image File Format, a standard established in 1998 for embedding metadata inside image files. Every modern digital camera and smartphone automatically writes EXIF data into every photo it takes. The data is stored as a series of tagged fields appended to the JPEG file header (specifically inside the APP1 marker segment) without altering the visible image content.

The depth of information stored in EXIF can be surprising. Beyond the obvious camera settings, a typical JPEG from a smartphone contains the GPS latitude and longitude at which the photo was taken, the altitude, the compass direction the camera was pointing, the precise timestamp (including timezone in newer phones), the device model and serial number, the software version used to process the image, the lens focal length, whether a flash fired, the metering mode, white balance setting, and in some cases the user's name or copyright string. Sharing photos publicly without stripping EXIF data can inadvertently reveal home addresses, daily routines, and device identifiers.

The File Analyzer extracts and displays EXIF fields for JPEG files. PNG files do not carry EXIF in the same way — they use their own chunk system where metadata is optional and often absent. HEIC files (common on iPhones) use an EXIF-compatible structure but require additional parsing support. WebP and modern AVIF images may embed XMP or EXIF segments depending on the software that created them.

The GPS coordinates in EXIF are stored as degrees, minutes, and seconds in separate fields and converted to decimal degrees for display. When present, the coordinates can be pasted directly into Google Maps or any mapping service to show exactly where the photo was taken — precise to within a few metres. This is enormously useful for photographers cataloguing field work, but is a significant privacy exposure for personal photos shared publicly.

MIME type detection from magic bytes

File extensions are just labels — they can be renamed or wrong. The analyzer reads the file's magic bytes (the first 4-16 bytes) to identify the actual format. For example, all JPEG files start with FF D8 FF regardless of their extension. This is the same technique used by operating system utilities, antivirus scanners, and forensics tools to classify files reliably.

Text-based formats — HTML, JSON, CSV, XML, JavaScript — do not have fixed magic bytes because they start with arbitrary printable characters. For these formats, the analyzer falls back to extension-based detection and heuristic content scanning (checking whether the file contains valid UTF-8 text and looking for structural clues like opening curly braces for JSON or angle brackets for HTML/XML).

File size, encoding, and what they reveal

The analyzer reports file size in both raw bytes and human-readable form (KB or MB). Raw byte counts are important in development contexts where you need to compare against API payload limits, check that a file fits within an upload quota, or verify that a compression step actually reduced file size by the expected amount.

For text files, the character encoding is a common source of bugs. A UTF-8 file and a UTF-16 file containing the same text will have very different byte sizes — UTF-16 uses at minimum two bytes per character and starts with a byte order mark (BOM) FF FE or FE FF. UTF-8 with BOM starts with EF BB BF. Legacy Windows encodings (Windows-1252) and ISO-8859-1 have no BOM and are indistinguishable from each other or from UTF-8 in the first few bytes — you must scan for byte values above 0x7F that are invalid in ASCII to begin to differentiate them. The hex viewer makes all of this visible at a glance.

Image files carry additional size-relevant metadata. The analyzer reports pixel dimensions (width and height), which you can use to quickly verify that an image meets a required resolution — useful for checking profile pictures, banner images, or print-ready artwork without opening an image editor. Color depth (8-bit per channel, 16-bit per channel) and whether the image has an alpha (transparency) channel are also reported where the format stores them in the header.

SHA-256 file hash

The SHA-256 hash is computed using SubtleCrypto's digest method on the full file content. This gives you a 64-character hex string that uniquely identifies the file contents. Useful for:

SHA-256 belongs to the SHA-2 family of cryptographic hash functions. It produces a 256-bit (32-byte) output, represented as 64 hexadecimal characters. The key property is collision resistance: it is computationally infeasible to find two different files that produce the same SHA-256 hash. This means if two files share an identical SHA-256 value, you can be certain their contents are identical down to the last bit.

Software publishers routinely post SHA-256 checksums alongside download links for operating system images, security tools, and software packages. Before installing critical software, computing the hash of your download and comparing it against the published value is one of the most reliable ways to verify the file was not tampered with in transit or on the mirror server. The File Analyzer makes this check trivial — drop the downloaded file, copy the hash, compare it against the publisher's listed value.

Use cases: security, debugging, and forensics

File analysis with magic bytes and metadata is used across a range of professional contexts — not just by security researchers. Here is how different practitioners benefit from this kind of inspection.

Security screening. The most immediately valuable application is detecting disguised files. Malware distribution often involves renaming executables or scripts with innocuous extensions (.jpg, .pdf, .docx) to trick users into opening them. By checking magic bytes against the declared extension, you can catch the most obvious cases. An email attachment named "Q3-report.pdf" that opens as 4D 5A (Windows PE executable) is an immediate red flag. Similarly, a file with the MIME type application/x-msdownload masquerading as a ZIP should be treated with extreme caution. This is not a replacement for a full antivirus scan — the tool does not examine file contents for known malware signatures — but it is a fast, reliable first pass.

Debugging upload failures. Web application developers frequently encounter upload validation failures that are hard to diagnose. A server may reject a file because the MIME type it detects from magic bytes conflicts with the extension, because the file is actually a different format than expected, or because its size exceeds an undocumented limit. Dropping the file into the analyzer tells you what the server will likely see — the true MIME type, exact byte count, and whether the header looks corrupt. This saves significant back-and-forth debugging time.

Digital forensics and incident response. During a security incident, analysts often encounter files with unknown provenance. Determining the true type, computing a hash for comparison against threat intelligence databases, inspecting the byte-level header, and extracting embedded timestamps from EXIF or document properties are all standard first steps in triage. A browser-based tool is particularly useful in restricted environments where installing forensics software is not permitted, or when working on a machine that may itself be compromised (so local tools should not be trusted).

Photography and media workflows. Photographers and content teams often need to verify image properties before handing files off — confirming resolution, checking that GPS data is present (or absent, for privacy), verifying the shooting date embedded in EXIF matches editorial records, and checking that image dimensions meet publication requirements. The File Analyzer handles all of this in one drop without requiring Lightroom, Photoshop, or any other installed software.

Archive inspection. Files inside ZIP archives often have opaque or abbreviated names. Before extracting and executing a script or binary, dropping it on the analyzer first — to verify it matches its claimed type and has no suspicious characteristics — is a simple but effective safety habit. The hex viewer lets you see the first few hundred bytes of any file, which is enough to spot obvious anomalies in the header even without specialist knowledge.

Privacy: local analysis with no uploads

Every step of the analysis happens inside your browser's JavaScript engine. The browser's File API provides JavaScript with read access to file contents through a sandboxed interface that is specifically designed to prevent the page from transmitting your file data without your knowledge. The File object is readable in memory but is not accessible to the network stack unless your code explicitly creates a network request containing it.

The SHA-256 hash is computed using the Web Crypto API's SubtleCrypto.digest() method, a native browser implementation of cryptographic hashing that runs entirely within the browser process. No external library or server endpoint is involved in the hashing step. The EXIF parser is a JavaScript library that reads the binary buffer you hand it in memory.

This matters significantly for the files most likely to benefit from analysis: sensitive corporate documents, confidential client data, medical images with patient information in EXIF, source code under NDA, and security-relevant files like SSH keys or certificates. Any online tool that requires uploading these files to a remote server introduces a data-handling risk — legal, regulatory, or practical — that a fully client-side tool avoids by design.

You can verify the privacy guarantee yourself: open your browser's Network panel in DevTools before dropping any file, then watch for outbound POST requests while the analysis runs. You will find none carrying your file data. The only requests you will see are the initial page load and any cached static assets already delivered by the browser.

Frequently Asked Questions