How to hex editor vs hex inspector: choosing the right tool
- Step 1Decide: are you reading or writing? — If you only need to read the header (confirm a signature, read a field, eyeball strings), the inspector is the lighter choice. If you need to modify bytes and save, you need a desktop hex editor — the inspector has no write path.
- Step 2Check the byte window you need — The inspector shows 256 B (Free), 1 KB (Pro / Pro+Media), or 8 KB (Developer). If your field of interest is within 8 KB of the start, the inspector reaches it. If it's deeper, or mid-file, use a desktop editor that can seek.
- Step 3Drop the file into the inspector — Drag the binary in or click to browse (
*/*accepted). The inspector reads the whole file into memory, so it must fit your plan's size limit (10 MB Free → 2 GB Developer). A 4 GB disk image won't load here — that's a desktop-editor job. - Step 4Read the dump — Offset on the left, 16 uppercase hex bytes per row in the middle, ASCII sidebar on the right. Non-printable bytes (including
0x7F) show as dots. This is the same mental model asxxdand HxD's default view. - Step 5Copy bytes if you need them elsewhere — The Copy button yields a continuous lowercase hex string (not the offset/ASCII layout). Paste it into a note, or into a desktop editor's hex-paste if you then need to edit.
- Step 6Escalate to a desktop editor when warranted — Need to patch a byte, run a binary template (010 Editor), search across the whole file, or read past 8 KB? Switch to HxD, 010 Editor, or
xxd. The inspector handled the triage; the editor handles the surgery.
Hex inspector vs desktop hex editors — head to head
Capabilities grounded in the actual inspector implementation versus typical desktop hex editors. 'Inspector' = the JAD browser tool; 'Desktop' = HxD / 010 Editor / xxd.
| Capability | Hex Inspector (browser) | Desktop editor (HxD / 010 / xxd) |
|---|---|---|
| Install required | None — runs in any browser | Yes (HxD/010) or shell access (xxd) |
| Edit / write bytes | No — strictly read-only | Yes |
| Offset + ASCII layout | Yes — 8-digit offset, 16 bytes/row, ASCII sidebar | Yes |
| Bytes visible | 256 B / 1 KB / 8 KB by tier | Whole file |
| Seek to arbitrary offset | No — always reads from offset 0 | Yes |
| In-tool search | No search box | Yes (find hex / text) |
| Field templates / annotations | None | 010 Editor binary templates; HxD bookmarks |
| Max file it will open | Plan limit (10 MB → 2 GB) | Multi-GB, memory-mapped |
| Privacy | Local — file read in-browser, not uploaded | Local (desktop app) |
| Accidental-overwrite risk | Zero (no write path) | Possible (defaults to read-write) |
Pick by task
Match the job to the tool. The inspector wins for read-only triage within the first few KB; the desktop editor wins for editing, searching, and large/mid-file work.
| Your task | Best tool | Why |
|---|---|---|
| Confirm a magic byte / file signature | Inspector | 256 B window covers virtually every signature; no install |
| Read a header field within the first 8 KB | Inspector (Developer) | 8 KB window plus the offset column lands you on the field |
| Check a header on a machine you can't install on | Inspector | Browser-only; nothing to install |
| Patch a byte and save | Desktop editor | Inspector is read-only — no write path |
| Search a whole file for a byte pattern | Desktop editor | Inspector has no search box and a capped window |
| Read a mid-file signature (SFX archive) | Desktop editor | Inspector always starts at offset 0 |
| Open a 4 GB disk image | Desktop editor | Inspector reads the whole file into memory under a plan limit |
| Parse a struct with a template | 010 Editor | Inspector has no templates or field annotations |
Cookbook
Concrete decisions: the same starting question, resolved to the right tool. Dumps show the inspector's on-screen layout (offset · hex · ASCII).
Quick 'is this really a PDF?' — inspector wins
A teammate sends report.pdf that won't open. You don't need to edit anything — you just need to see the first bytes. The inspector answers in seconds without installing anything.
Drop report.pdf → inspector dump (offset 0):
00000000 50 4B 03 04 14 00 06 00 08 00 00 00 21 00 ... PK..........!.
Verdict: 50 4B 03 04 ('PK..') is a ZIP, not a PDF
(%PDF- = 25 50 44 46 2D). The file was mis-saved or
mis-named. No desktop editor needed.Patch a corrupt length field — desktop editor wins
You diagnosed a wrong chunk-length DWORD in a PNG and need to write the correct value back. The inspector cannot do this — it has no write path. This is a desktop-editor job.
Inspector (read-only) shows the bad field:
00000008 00 00 FF 0D 49 48 44 52 ... ....IHDR
^^^^^^^^ length looks wrong (should be 00 00 00 0D)
To fix: open in HxD or 010 Editor, overwrite the 4 bytes,
save. The inspector identified the problem; the editor
writes the repair.Find a byte pattern anywhere in a 200 MB file — desktop editor wins
You need to locate every occurrence of a marker across a large file. The inspector caps at 8 KB and has no search box, so it can't do a full-file scan. Use a desktop editor's find.
Inspector limitation: - window caps at 8 KB (Developer) - no in-dump search box Desktop approach (xxd + grep, or HxD find): $ xxd big.bin | grep '504b 0304' # all ZIP locals → lists every offset where the pattern appears
Triage a suspicious file on a hardened workstation — inspector wins
Incident response on a machine where you cannot install software. The browser inspector reads the header locally and shows the signature without touching the file system beyond the read.
No install allowed → open the inspector in the browser. Drop the quarantined sample: 00000000 4D 5A 90 00 03 00 00 00 04 00 00 00 ... MZ.......... Verdict in seconds: it's a PE executable. Read-only, so no chance of altering the sample. Escalate to a sandbox from there.
Read past 8 KB into a container — desktop editor wins
A self-extracting archive hides its real ZIP central directory far past the 8 KB the inspector can show. The inspector faithfully shows the stub at offset 0, but to seek deep you need a desktop tool.
Inspector (Developer, 8 KB window) shows only the stub: 00000000 4D 5A 90 00 ... MZ.. (executable wrapper) The PK 03 04 archive starts ~40 KB in — beyond the window and the inspector always reads from offset 0. Seek there in 010 Editor or with `xxd -s 0xA000`.
Edge cases and what actually happens
You need write access
Not availableThe inspector is read-only by construction — there is no write path in the tool. That eliminates accidental-overwrite risk, but it also means any byte editing must happen in a desktop hex editor (HxD, 010 Editor) or via xxd/dd.
Field of interest is deeper than 8 KB
Out of windowThe maximum window is 8 KB (Developer). Headers fully within 8 KB are reachable; anything deeper is not. The inspector always reads from offset 0 and cannot seek, so deep or mid-file fields require a desktop editor that supports a start offset.
File too large to load in the browser
RejectedThe inspector reads the whole file into memory and enforces the plan size limit (10 MB Free → 2 GB Developer). A 4 GB image is rejected. Desktop editors memory-map huge files and don't have this ceiling — use one for disk images and large captures.
You expected an in-tool find / search
Not availableThere is no search box in the hex view — it renders offset, hex, and ASCII rows only. Full-file or even in-window pattern search belongs to a desktop editor. As a workaround, copy the hex string out and search it in a text editor.
You expected binary templates / struct parsing
Not availableThe inspector has no template engine and no field annotations — it shows raw bytes. For struct-aware parsing (named fields, types, repeats), 010 Editor's binary templates are the right tool. The inspector is for fast visual reads, not formal parsing.
Read-only is exactly what you want for evidence
By designFor forensic integrity, the inability to write is a feature: you cannot alter the sample, so chain-of-custody is easier to argue. When that matters more than editing power, the inspector is the better default.
Copy output differs from a desktop editor's hex view
ExpectedThe inspector's Copy button yields a continuous lowercase hex string, while HxD/010/xxd copy can preserve offsets and spacing. If you paste the inspector's copy into a tool expecting grouped bytes, re-space it first.
Offline / air-gapped environment
DependsA browser tool needs the page loaded; a fully air-gapped host with no cached page can't open it. In that case a locally-installed desktop editor (or xxd on a Linux host) is the only option. On a connected analysis VM, the inspector works fine.
Frequently asked questions
Is the inspector a replacement for HxD or 010 Editor?
For read-only header inspection within the first 8 KB, yes — it gives you the same offset/hex/ASCII layout with no install. For editing bytes, searching whole files, seeking to arbitrary offsets, opening multi-GB files, or struct templates, no — keep a desktop editor for those.
Why would I use a browser tool over xxd?
When you don't have shell access, are on Windows without WSL, or are on a machine where you can't install anything. The inspector's output mirrors xxd (offset, hex, ASCII), so the mental model transfers directly. For scripting and full-file work, xxd still wins.
Can the inspector accidentally modify my file?
No. It has no write path — it reads bytes into memory and renders them. This is a deliberate safety property: you cannot overwrite evidence the way you can with a read-write desktop editor left in the wrong mode.
How many bytes can I see compared to a desktop editor?
The inspector shows 256 B (Free), 1 KB (Pro / Pro+Media), or 8 KB (Developer). Desktop editors show the whole file. If your target is within 8 KB of the start, the inspector reaches it; otherwise use a desktop tool.
Does the inspector have a search box like HxD?
No. The hex view has no in-dump search. To search, copy the hex string out and search in a text editor, or use a desktop editor's find. Search across a whole file is specifically a desktop-editor capability.
Can I seek to a specific offset like in 010 Editor?
No — the inspector always reads from offset 0 and shows the first N bytes. It cannot start at an arbitrary offset. For a mid-file seek (e.g. xxd -s), use a desktop tool.
Does it annotate header fields like a template?
No field annotations or templates — it shows raw offset/hex/ASCII. You interpret the structure yourself. For automatic file-type detection use magic-byte-validator; for struct parsing use 010 Editor templates on the desktop.
What's the biggest file each can open?
The inspector caps at the plan size limit (10 MB Free → 2 GB Developer) because it loads the whole file into memory. Desktop editors memory-map files and handle multi-GB images comfortably. For disk images, use the desktop.
Is the inspector safe for suspected-malware files?
Yes — it never executes the file, only reads its bytes, and it's read-only. Combine it with magic-byte-validator and entropy-analyzer for a fuller, still-non-executing triage before sandbox detonation.
Can I edit in the inspector and download the result?
You can download the bytes the inspector read (as a hex string), but you cannot edit them in the tool first. There is no editing surface. To produce a modified binary, edit in a desktop editor and save from there.
Which is faster for a one-off header check?
The inspector — drop the file, click Run, read the dump. No app launch, no project setup. For repeated or scripted work, a desktop editor or xxd pipeline is faster overall.
Does using the inspector send my file anywhere?
No. The on-page tool reads the file locally with FileReader and renders in-browser; nothing is uploaded. A desktop editor is also local, so on privacy both are equivalent — the difference is install footprint and write capability.
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.