How to fingerprint a file so support knows you have the exact same copy
- Step 1Fingerprint the exact file you're reporting on — Drop the file you'll attach or describe — the failing input, the export, the config — and run. Hash the real file you reproduced the issue with, not a freshly regenerated copy, so the digest matches what you tested.
- Step 2Copy the SHA-256 into the ticket — From the JSON report, copy the
sha256value (64 hex chars). Paste it into the bug report alongside the filename and size, e.g. "export.csv — 48,210 bytes — sha256 9b74c98…". This is the line the engineer will reproduce. - Step 3Attach the file (or keep it local) as needed — If the file is shareable, attach it; the hash lets the engineer confirm the attachment arrived intact. If it's confidential, share only the hash — the engineer reproduces with their own equivalent file and compares digests to see if they truly match yours.
- Step 4Have the engineer recompute and compare — The engineer runs
sha256sum(or this tool) on their copy. Equal digest: confirmed same bytes — the bug is reproducible on identical input. Different digest: the files differ, and that difference is the next thing to investigate. - Step 5If hashes differ, diagnose the difference — A mismatch on a 'same' text file usually means line endings (CRLF vs LF), encoding, a BOM, or a trailing newline. Normalize both files to byte-identical and re-hash, or treat the divergence itself as the reproduction detail to report.
- Step 6Re-hash after any fix to confirm the change — When a fix changes the file (a corrected config, a regenerated export), fingerprint the new version and note the new SHA-256 in the ticket. A changed digest is hard evidence that the file actually changed between the broken and fixed states.
What a shared hash proves in a support thread
How a SHA-256 in a ticket resolves the ambiguities that stall reproductions.
| Situation | Without a hash | With a matching SHA-256 |
|---|---|---|
You and support both have data.csv | Maybe the same file, maybe not — no way to know | Proven byte-identical; the bug is on identical input |
| You attached a file; did it arrive intact? | Assume so; corruption goes unnoticed | Engineer's hash of the attachment matches yours = intact |
| Engineer 'can't reproduce' | Could be code, env, or a different file | Hash mismatch rules out 'different file' (or pinpoints it) |
| A fix supposedly changed the config | Trust the claim | New SHA-256 proves the file actually changed |
Reading the report for a ticket
Every run returns all four digests. SHA-256 is the one to quote; the others cover ticket templates that still ask for legacy checksums.
| Report field | Length | When to quote it |
|---|---|---|
sha256 | 64 hex chars | Default — the digest to paste into any modern ticket |
md5 | 32 hex chars | Only if a legacy template/system explicitly asks for an MD5 |
sha1 | 40 hex chars | Rarely — for systems that record SHA-1 file checksums |
sha512 | 128 hex chars | If the engineer asks for extra assurance |
Limits and privacy
Browser-side hashing; the file's bytes stay local, only the digest is shared.
| Property | Value | Notes |
|---|---|---|
| Where it runs | In your browser (Web Crypto API) | File is read into memory locally; the digest is what you copy |
| File-size limit (Free / Pro / Pro-media / Developer) | 10 MB / 100 MB / 500 MB / 2 GB | Oversize files rejected before hashing |
| Files per run | 1 (the first dropped file) | Hash one file per ticket; repeat for more |
| Output | JSON { sha1, sha256, sha512, md5 }, lowercase hex | Copy the sha256, or download <filename>.hashes.json to attach |
Cookbook
Ways to put a hash to work in support and reproducibility threads. The tool gives you the digest; the value is in how you share and compare it. CLI equivalents let the other side reproduce without this tool.
Add a file fingerprint to a bug report
Quote the filename, size, and SHA-256 in the report so the engineer can confirm they're testing the same input. This single line eliminates the 'did you regenerate the file?' back-and-forth.
Steps to reproduce:
1. Import the attached export.csv
- size: 48,210 bytes
- sha256: 9b74c9897bac770ffc029102a200c5de8642f8...
2. Run the report -> totals are wrong
Engineer cross-checks: sha256sum export.csv (should match).Confirm an attachment arrived intact
Email and ticket systems can re-encode or truncate attachments. Put the SHA-256 in the message body; the recipient hashes the downloaded attachment and a match proves it arrived byte-for-byte intact.
Body: attachment crash.dmp sha256 = 2c26b46b68ffc68ff99b453c1d304134c8c5d8f4... Recipient: sha256sum crash.dmp match -> intact, safe to analyze differ -> the transfer mangled it; resend
Share a hash for a confidential file you can't attach
When the failing input contains customer data you can't upload, share only its SHA-256. The engineer reproduces with their own equivalent file; if their hash matches yours, you have provably the same bytes — without the sensitive data ever leaving your machine.
You (locally): customer-2026-04.json sha256 = fcde2b2edba56bf408601fb721fe9b5c338d10ee... Engineer builds an equivalent file, hashes it: match -> same bytes, proceed (no data shared) differ -> your file has content theirs doesn't; describe it
Prove a config actually changed after a fix
Support says the fix updated your config file. Fingerprint it before and after applying the fix; a different SHA-256 is hard proof the file changed. An unchanged hash means the fix didn't touch the file you think it did.
Before fix -> sha256: 0a0a9f2a6772942557ab5355d76af442f8f6... After fix -> sha256: 7d865e959b2466918c9863afca942d0f89f8... Differ -> the config genuinely changed. Same -> the fix did not modify this file; dig deeper.
Quote an MD5 for a legacy ticket template
An older internal tracker's template asks for an 'MD5 file checksum.' It's already in the report — copy the md5 line. For your own correlation, still rely on the sha256, since MD5 is only a corruption check.
Ticket field 'MD5 checksum': report md5 -> 9e107d9d372bb6826bd81d3542a419d6 (Internally correlate on sha256 instead: 9b74c9897bac770ffc029102a200c5de... MD5 is collision-broken, fine only for corruption detection.)
Edge cases and what actually happens
Engineer regenerated the file instead of using yours
Mismatch expectedIf support exports their own copy rather than using your exact attachment, the bytes (and the hash) will differ even for the 'same' query — timestamps, ordering, or encoding vary. That's why you quote a hash: a mismatch tells you immediately you're not testing identical input. Ask them to hash your attachment, not a regenerated file.
Attachment was re-encoded by email/ticket system
Corruption detectedSome systems recompress, re-encode, or add headers to attachments. If the recipient's hash of the downloaded file doesn't match the one you quoted, the transfer altered the bytes. Re-send as a zip or via a channel that preserves the file, then re-confirm the hash.
Same text file, different hash on the two machines
By designLine endings (CRLF vs LF), a UTF-8 BOM, or a trailing newline make 'identical-looking' text files byte-different, so the hashes differ. This isn't a tool error — it's often the actual cause of an environment-specific bug. Normalize both files to byte-identical, or report the difference as a reproduction detail.
Published/quoted hash is uppercase, report is lowercase
ExpectedThe report emits lowercase hex; Windows certutil and some tools print uppercase. Hex is case-insensitive as a value, so lowercase ab12… equals uppercase AB12…. Compare case-insensitively — it's not a mismatch.
You want to send the hash but not the file, and they have nothing to compare
LimitedA hash only helps if both sides can produce a copy to hash. If the engineer has no equivalent file, your digest alone can't reproduce the bug — it can only later confirm a file they obtain is the right one. In that case you still need a safe way to share the file (e.g., redact it first with email-phone-scrubber for PII).
File is larger than your tier's limit
Rejected: too largeThe whole file is read into memory before hashing: Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. A large crash dump or log over your cap is rejected with an 'exceeds the … limit for your plan' error. For oversize files, hash with sha256sum locally and quote that value (it'll match this tool's output).
No file dropped before running
Error: no fileThere's no text-paste mode — drop the actual file. Running with an empty dropzone throws 'No file provided.' (To analyze a typed password/secret string instead of a file, use password-entropy-auditor.)
You quoted MD5 and someone questions its security
Insecure for trustMD5 is collision-broken, so it can't prove a file is safe against a deliberate attacker — but for confirming two cooperating parties have the same non-adversarial file, an MD5 match is a fine corruption-and-correlation check. For anything security-sensitive, quote the SHA-256 instead; it's right there in the same report.
The file contains PII you shouldn't share even hashed
Use a redaction tool firstA hash doesn't reveal contents, so sharing a digest is safe — but if you must share the actual file with support, scrub identifiers first with email-phone-scrubber or csv-json-data-scrambler, then hash the redacted copy so both sides correlate on the version that's safe to share.
Frequently asked questions
How does a hash help a support ticket?
It removes the biggest unknown in a reproduction: whether both sides have the same file. You compute the SHA-256 of your failing input and put it in the ticket; the support engineer computes the SHA-256 of their copy. A match proves you're both testing byte-identical input, so the bug is genuinely about the code or environment. A mismatch proves the files differ — which is frequently the real cause.
Do I have to upload the file to get its hash?
No. The file is read into memory in your browser and hashed locally with the Web Crypto API — nothing is uploaded. You copy the resulting digest into the ticket, not the file. That's exactly why this is safe for confidential exports, customer data, and internal logs: you can share the fingerprint while the sensitive bytes never leave your machine.
Which hash should I quote in a ticket?
SHA-256 — it's the modern default, it's what sha256sum/shasum produce, and any engineer can reproduce it with standard tools. Only quote MD5 or SHA-1 if a legacy ticket template explicitly asks for it. All four digests are in every report, so you can satisfy an old template's MD5 field while still correlating on SHA-256 yourself.
Can the engineer reproduce my hash without this tool?
Yes. The output matches sha256sum (Linux), shasum -a 256 (macOS), and certutil -hashfile … SHA256 (Windows) byte-for-byte. The engineer runs whichever they have on their copy of the file and gets the same value if it's the same bytes. No special software is required on their end — just the standard checksum command.
Our hashes don't match but the file 'looks the same' — why?
Some byte differs. For text, the usual culprits are line endings (Windows CRLF vs Unix LF), a UTF-8 BOM, or a trailing newline an editor added. For other files, one copy may have been re-saved or carry metadata the other lacks. The hash is doing its job by flagging the difference — and that difference is often exactly the environment-specific detail that explains the bug.
What if the file is too sensitive to share at all, even redacted?
Share only the hash. The engineer can't see contents from a digest, so quoting the SHA-256 is safe. They reproduce with their own equivalent file; if their hash matches yours, you've confirmed identical bytes without any data changing hands. If they truly need the file, redact identifiers first (for example with email-phone-scrubber) and hash the redacted copy so you both correlate on the shareable version.
Can a hash prove a fix actually changed my file?
Yes. Fingerprint the file before applying the fix and again after. A different SHA-256 is hard proof the file's bytes changed; an identical SHA-256 proves the fix didn't touch that file at all — useful when a change 'should have' updated a config but the symptom persists. The digest is byte-derived, so even a one-character change is detectable.
Is MD5 good enough for a support correlation?
For two cooperating parties confirming they have the same non-adversarial file, an MD5 match is fine — it's a perfectly good corruption-and-correlation check. MD5 is only unsafe when you're defending against a deliberate attacker who could craft a collision, which isn't the situation in a normal support thread. Still, prefer SHA-256 when it's available, since it's right there in the same report and removes all doubt.
Will an attachment that gets corrupted in transit be caught?
Yes, if you quote the hash. Email and ticket systems sometimes re-encode or truncate attachments. Put the SHA-256 in the message body; the recipient hashes the downloaded file and compares. A mismatch means the transfer altered the bytes, so they should request a re-send (often a zip survives where a raw file doesn't). A match confirms it arrived intact.
How big a file can I hash for a ticket?
Up to your tier's security file-size limit: Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. The whole file is read into memory before hashing — there's no streaming — so large crash dumps or logs are bounded by both the cap and browser memory. For a file over the cap, run sha256sum locally and quote that value; it matches this tool's output exactly.
Can I hash several attachments for one ticket?
Each run hashes the first dropped file only, so fingerprint them one at a time and list each filename with its SHA-256 in the ticket. That gives the engineer a per-file checklist to confirm every attachment matches. For scripted batch hashing of many files, the server-safe runner path can loop over them without uploading anything.
Does sharing a hash leak anything about the file?
No meaningful information. A SHA-256 is a fixed-length, one-way digest — you can't reverse it to recover the contents, and it reveals nothing about the data inside. That's what makes it safe to paste into a public-ish ticket even for a confidential file. It only lets someone who already has a candidate file check whether it's the same one.
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.