How to inspect file bytes in hex with an ascii sidebar
- Step 1Drop the file you want to inspect — Drag any file onto the drop zone, or click to browse. The tool accepts any type (
*/*). It reads the whole file into memory first, then slices the header — so the file itself must fit under your plan's security file-size limit (10 MB Free, 100 MB Pro, 500 MB Pro+Media, 2 GB Developer), even though only the first few hundred bytes are shown. - Step 2Run the inspector — Click Run Hex Inspector. Processing happens in your browser — the file is read with
FileReader, the first N bytes are sliced (N = your tier cap), and the dump renders below. Nothing is uploaded. - Step 3Read the offset column first — The left column is the byte offset in hex, zero-padded to 8 digits and uppercased (
00000000,00000010,00000020, …). Each row advances by 16 (0x10). Use it to translate a documented offset like0x3Cto the right row and column. - Step 4Read the magic bytes at offset 0 — The first row holds the file signature.
4D 5A(MZ) is a DOS/PE executable,7F 45 4C 46is ELF,89 50 4E 47is PNG,25 50 44 46(%PDF) is PDF,50 4B 03 04(PK..) is ZIP/OOXML. The ASCII sidebar makes text-like signatures instantly obvious. - Step 5Scan the ASCII sidebar for strings and padding — Readable runs in the sidebar (version strings, format tags,
JFIF,ftyp,IHDR) tell you the sub-format. Long stretches of.are binary or padding. A header that is almost entirely.with no readable structure is a hint the content may be compressed, encrypted, or packed. - Step 6Copy or download for your report — Use Copy to grab the sliced bytes as one continuous lowercase hex string (no offsets, no spaces) for pasting into a ticket or pattern search, or Download to save the same hex string as a text file. For quantitative randomness confirmation, send the file through entropy-analyzer; to confirm the extension matches the bytes, use magic-byte-validator.
What the three columns actually show
The on-screen hex view (HexViewer component) versus the Copy / Download payload. They are not the same format — read this before pasting a dump into a tool that expects offsets.
| Element | How it renders on screen | Notes |
|---|---|---|
| Offset column | 8 hex digits, uppercase, zero-padded, advancing by 16 per row (00000000, 00000010, …) | Always starts at offset 0 — the inspector reads from the start of the file, not an arbitrary seek point |
| Hex bytes | 16 bytes per row, each an uppercase 2-digit pair, space-separated (4D 5A 90 00 …) | Short final rows are padded with spaces so the ASCII column stays aligned |
| ASCII sidebar | One char per byte: bytes 0x20–0x7E print as their character, all others (control, high-bit, and 0x7F) print as . | 0x7F (DEL) prints as a dot — the printable test is >= 0x20 && < 0x7F, so it is exclusive of 0x7F |
| Copy / Download payload | One continuous lowercase hex string — no offsets, no spaces, no ASCII (4d5a9000…) | This is the raw bytesToHex output. It is NOT xxd format; re-space it yourself if a downstream tool needs grouped bytes |
Tier-capped hex window and file-size limits
The number of bytes the dump shows is fixed by your plan (there is no slider in the UI). Separately, the whole file must fit under the security file-size limit because the inspector reads the entire file before slicing the header.
| Plan | Hex window shown | Whole-file size limit | Files per run |
|---|---|---|---|
| Free | 256 bytes | 10 MB | 1 |
| Pro | 1,024 bytes (1 KB) | 100 MB | 1 |
| Pro + Media | 1,024 bytes (1 KB) | 500 MB | 1 |
| Developer | 8,192 bytes (8 KB) | 2 GB | 1 |
Common signatures you will read in the first row
The opening bytes that identify the most-inspected formats, shown as the inspector renders them (uppercase hex) with the ASCII the sidebar produces.
| Format | Magic bytes (hex) | ASCII sidebar | Offset |
|---|---|---|---|
| DOS / Windows PE | 4D 5A | MZ | 0 |
| ELF (Linux/Unix) | 7F 45 4C 46 | .ELF | 0 |
| PNG | 89 50 4E 47 0D 0A 1A 0A | .PNG.... | 0 |
| JPEG (SOI) | FF D8 FF | ... | 0 |
25 50 44 46 2D | %PDF- | 0 | |
| ZIP / OOXML / JAR | 50 4B 03 04 | PK.. | 0 |
| GIF | 47 49 46 38 | GIF8 | 0 |
| MP4 / MOV (ftyp box) | 66 74 79 70 | ftyp | 4 |
Cookbook
Worked dumps from real first-pass triage. Each shows the rows you would read on screen (offset · hex · ASCII), since that is how the inspector renders — not the flat string the Copy button produces.
Confirming a PNG by its 8-byte signature
PNG has an unusually long, deliberate magic sequence designed to survive byte-stripping transfers. The inspector's ASCII sidebar makes PNG pop out immediately, and the IHDR chunk name appears a few bytes later.
On-screen dump (first two rows, 256 B window on Free): 00000000 89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 .PNG........IHDR 00000010 00 00 04 00 00 00 03 00 08 06 00 00 00 ... ............... Read it: 89 50 4E 47 0D 0A 1A 0A → PNG signature 00 00 00 0D → IHDR chunk length (13 bytes, big-endian) 49 48 44 52 → 'IHDR' chunk type 00 00 04 00 / 00 00 03 00 → width 1024, height 768 (big-endian)
Spotting a renamed executable inside a .jpg
A file named invoice.jpg should open with FF D8 FF. When the inspector shows 4D 5A (MZ) at offset 0 instead, the file is a Windows executable wearing an image extension — a classic disguise. The ASCII sidebar shows the MZ plainly.
File on disk: invoice.jpg On-screen dump (offset 0): 00000000 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 MZ.............. Read it: Expected for JPEG: FF D8 FF Actual: 4D 5A → DOS/PE 'MZ' stub, NOT a JPEG Next step: run magic-byte-validator to get the detected type label and the extension-vs-content verdict in one click.
A header that is almost all dots — likely packed or encrypted
When the ASCII sidebar is a near-solid wall of . with no readable version strings or format tags, the bytes have no low-byte structure — typical of compressed, encrypted, or packed content. The inspector shows this visually; quantify it with the entropy analyzer.
On-screen dump (first row of an unknown blob): 00000000 A7 3F C1 9E 04 D2 6B FA 88 1C E0 57 B3 2D 9A 41 .?....k....W.-.A Read it: No magic bytes, no readable runs in the sidebar — almost every byte falls outside 0x20–0x7E and renders as '.' Next step: entropy-analyzer scores 256-byte chunks; >7.5 bits/byte across the file confirms compression/encryption.
Reading the MP4 ftyp brand from the second row
MP4/MOV files do not start with a magic byte at offset 0 — they start with a box-length DWORD, then the ftyp tag at offset 4, then a brand like isom or mp42. The offset column lets you land exactly on byte 4.
On-screen dump (first row, 256 B window): 00000000 00 00 00 18 66 74 79 70 69 73 6F 6D 00 00 02 00 ....ftypisom.... Read it: 00 00 00 18 → ftyp box size (24 bytes, big-endian) 66 74 79 70 → 'ftyp' at offset 4 69 73 6F 6D → major brand 'isom' at offset 8
Copying bytes for a ticket — what actually lands on the clipboard
The Copy button does not copy the offset/ASCII layout you see — it copies the sliced bytes as one continuous lowercase hex string. Know this before pasting into a tool that expects spaced bytes or offsets.
On screen (what you read): 00000000 4D 5A 90 00 03 00 00 00 MZ...... What Copy puts on your clipboard: 4d5a900003000000... To turn it back into spaced pairs for a Yara-style note, re-group the string yourself: 4d 5a 90 00 03 00 00 00
Edge cases and what actually happens
File is larger than your plan's size limit
RejectedThe inspector reads the entire file into an ArrayBuffer before slicing the header. If the file exceeds your security file-size limit (10 MB Free, 100 MB Pro, 500 MB Pro+Media, 2 GB Developer) it is rejected with a message like exceeds the 10 MB limit for your plan — even though only the first 256 bytes would be shown. Trim the file with a desktop tool, upgrade, or inspect a smaller sample.
You want more than your tier's byte window
By designThe window is fixed by plan: 256 B Free, 1 KB Pro / Pro+Media, 8 KB Developer. There is no slider in the UI to raise it — the informational note above the result just states the active cap. To see beyond 8 KB, use a desktop tool such as xxd, HxD, or 010 Editor; in-browser DOM rendering of large dumps is the reason for the cap.
0x7F (DEL) shows as a dot, not a character
ExpectedThe printable test is >= 0x20 && < 0x7F, which excludes 0x7F. So the DEL control byte renders as . in the ASCII sidebar like any other non-printable byte. This is intentional — 0x7F is a control character, not a glyph.
Signature appears mid-file, not at offset 0
PreservedThe inspector always reads from offset 0. A self-extracting ZIP prepends an executable stub, so the PK 03 04 signature can sit thousands of bytes in — beyond even the 8 KB Developer window. The dump faithfully shows the real first bytes (the MZ stub), not the embedded archive. Use a desktop hex editor to seek to the mid-file signature.
Empty (zero-byte) file
Empty resultA zero-byte file slices to zero bytes; bytesShown is 0 and the dump is empty. There is nothing to read — the file has no header. This is expected, not an error.
Copy output is not xxd format
By designThe Copy and Download payload is the raw bytesToHex result: a continuous lowercase hex string with no offsets, no spaces, and no ASCII column. It is not interchangeable with xxd output. If a downstream parser expects grouped bytes or an offset column, re-format the string yourself.
Expecting a search box to find a byte sequence
Not availableThe hex view does not include an in-dump search box — it renders offset, hex, and ASCII rows only. To find a sequence, copy the hex string and search it in your text editor, or use a desktop hex editor with find. Older copy describing a search box does not match the current tool.
Expecting colour-coded field annotations or tooltips
Not availableThe inspector renders raw bytes in a uniform monospace style. It does not colour-highlight magic-byte ranges, label known header fields, or show per-byte tooltips. You read the structure yourself against the format spec (the cookbook tables above give the common offsets). For an automatic content-type verdict, use magic-byte-validator.
Text file with high-bit (UTF-8) characters
ExpectedMulti-byte UTF-8 sequences (e.g. é = C3 A9) have bytes above 0x7E, so each continuation byte renders as . in the ASCII sidebar even though the text is valid. Read the hex pairs to reconstruct the codepoints — the sidebar only resolves single-byte ASCII.
Frequently asked questions
Does the file get uploaded to a server?
No. In the browser, the file is read into an ArrayBuffer with the FileReader API, sliced, and rendered entirely in-page JavaScript. No network request carries your bytes. A server-safe path exists for the public API, but the on-page tool runs locally.
How many bytes does each plan show?
Free shows the first 256 bytes, Pro and Pro+Media show 1,024 bytes (1 KB), and Developer shows 8,192 bytes (8 KB). The cap is fixed by tier — there is no byte-count slider in the UI. For most magic-byte and header reads, 256 bytes is already enough.
Why was my big file rejected when I only wanted the first 256 bytes?
The tool reads the whole file into memory before slicing the header, so the file as a whole must fit under your plan's security file-size limit (10 MB Free / 100 MB Pro / 500 MB Pro+Media / 2 GB Developer). It does not stream just the first bytes. Trim a sample with a desktop tool or upgrade your plan.
What does a dot in the ASCII sidebar mean?
A . stands for a byte that is not a printable ASCII character. The sidebar resolves only bytes in the range 0x20–0x7E to their character; everything else — control bytes, high-bit/UTF-8 continuation bytes, and 0x7F (DEL) — renders as a dot.
Is the on-screen format the same as what Copy gives me?
No. On screen you get offset + spaced uppercase hex + ASCII (xxd-like). The Copy button puts a single continuous lowercase hex string on your clipboard — no offsets, no spaces, no ASCII. Re-group it yourself if you need spaced pairs.
Can I see a byte at a specific offset like 0x3C?
Yes — use the offset column. Each row starts at a multiple of 16 (0x10). 0x3C is in the row labelled 00000030, at the 13th byte (0x3C − 0x30 = 0xC). Read the value, and if it's a little-endian DWORD pointer (like the PE e_lfanew), reverse the byte order to get the target offset.
Does it highlight or annotate known header fields?
No. The view shows raw offset/hex/ASCII with no colour coding, field labels, or tooltips. You interpret the structure against the format spec. For an automatic file-type identification, run the same file through magic-byte-validator, which matches against 300+ signatures via the file-type library.
Can I search the dump for a byte pattern?
Not inside the tool — there is no search box in the hex view. Copy the hex string out and search it in your editor, or use a desktop hex editor (HxD, 010 Editor) with built-in find for full-file pattern searches.
What file types can I inspect?
Any type — the drop zone accepts */* and the bytes are read raw. It works equally on executables, images, archives, documents, and unknown blobs. The inspector reports what's actually there; it never guesses or transforms the content.
How do I confirm a file is packed or encrypted from the dump?
Visually, a near-solid wall of dots in the ASCII sidebar with no readable strings is a strong hint. To quantify it, run the file through entropy-analyzer, which scores 256-byte chunks; values above ~7.5 bits/byte indicate compression or encryption.
Can the inspector edit or save modified bytes?
No — it is strictly read-only. There is no write path, so there is zero risk of accidentally altering the file you are examining. If you need to edit bytes, use a desktop hex editor; for read-only triage this tool is faster and safer.
What's the fastest first-pass triage workflow?
Drop the file into the Hex Header Inspector to read the signature, then magic-byte-validator to confirm the extension matches the content, then entropy-analyzer to flag packed regions. For a known-good baseline comparison of two captures, use file-integrity-monitor.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.