How to entropy analyzer — frequently asked questions
- Step 1Drop one file — Drop any file type. The drop area accepts multiple files, but the entropy view analyzes the first file only per run — so drop one at a time. It is processed in browser memory; no account is required for the free tier.
- Step 2Read the high-entropy readout — Top-right of the chart shows
{count} high-entropy chunks ({percent}%)— windows at or above 7.5 bits/byte. When that percentage exceeds 50%, the text turns amber, signalling the file-levelthreatDetectedcondition. - Step 3Scan the curve and the Max value — A flat high curve is expected for compressed files. A sudden spike inside a low baseline marks an embedded payload worth a look. The footer's
Maxis the single highest chunk — useful for spotting one extreme window. - Step 4Add context before concluding anything — Entropy alone cannot tell encryption from compression or malware from media. Confirm the file type with magic-byte-validator and the header with hex-header-inspector before treating high entropy as a finding.
- Step 5Use the right follow-up tool — Fingerprint a suspect with multi-hash-fingerprinter; decrypt a known AES blob with aes-256-encryptor; extract LSB-hidden data from a PNG/BMP with steganography-decoder.
- Step 6Mind your tier's size limit — Free handles 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. Over the cap, the tool rejects the file with a clear plan-limit error before charting anything.
What each readout number means
Every figure the analyzer shows, and how to read it. There is no averaged score anywhere in the UI.
| Readout | Where | Meaning |
|---|---|---|
{N} chunks · 256 bytes each | Top-left | How many 256-byte windows the file was split into |
{count} high-entropy chunks | Top-right | Windows with entropy >= 7.5 |
({percent}%) | Top-right | Share of windows that are high-entropy; amber when > 50% |
| Amber dashed line | On the chart at y=7.5 | The high-entropy boundary |
| Cyan curve | Chart body | Per-chunk entropy, fixed [0,8] Y-axis |
Max: X.XX bits/byte | Footer | Single highest chunk value (NOT an average) |
Why these files read high (and it's fine)
Common files that legitimately cross the amber 7.5 line because they are compressed or encrypted.
| File | Typical entropy | Why it's expected |
|---|---|---|
| MP3 / AAC / FLAC | 7.7 - 7.9 | Entropy-coded audio |
| JPEG | 6.8 - 7.3 | Lossy DCT + entropy coding |
| MP4 / MOV | 7.5 - 7.9 | Compressed video streams |
| ZIP / 7z | 7.6 - 8.0 | Compressed archive payloads |
| DOCX / XLSX / PPTX | 7.5 - 7.8 | Office files are ZIP containers |
| Encrypted file / key material | 7.95 - 8.0 | Near-uniform by design |
Tier file-size limits
The real per-tier ceilings for the Security family. Entropy-analyzer is free; you only need a higher tier for bigger files.
| Tier | Max file size | Files per run |
|---|---|---|
| Free | 10 MB | 1 |
| Pro | 100 MB | 5 |
| Pro-media | 500 MB | 50 |
| Developer | 2 GB | Unlimited |
Cookbook
How to read specific results. Values are representative; the analyzer rounds to 3 decimals and counts chunks at or above 7.5.
MP3 reads 7.8 across the whole curve
Your music file shows a flat high curve and the percentage is amber. That is normal — MP3 uses Huffman and entropy coding, producing near-maximal byte randomness just like ciphertext. High entropy on known media is expected, not a malware signal.
Readout: 14000 high-entropy chunks (97%) <- amber Max: 7.91 bits/byte threatDetected: true Verdict: this is what compressed audio looks like. Benign. The amber flag is about randomness, not safety.
A .txt that reads 6.0 in one spot
Mostly ~4.5 prose with one bump to ~6.0 — likely a base64 or hex blob pasted into the text. It stays below the amber line, so threatDetected is false, but the bump is visible and worth decoding.
Baseline: ~4.5 (English text) One region: ~6.0 (base64-encoded data) No amber flag (6.0 < 7.5), but the rise above the text baseline is the clue. Decode that region to see what it is.
An EXE flat above 7.5 — unusual
Most unpacked executables average 5.5-6.5 with low data zones. A whole-file plateau above 7.5 on an .exe is atypical and suggests packing or encryption. Confirm the header before concluding.
Readout: 9200 high-entropy chunks (90%) <- amber threatDetected: true Unusual for an EXE. Check the header (magic-byte-validator) for a packer marker; fingerprint and sandbox if unexplained.
Encrypted ZIP vs malware — same curve
Two files, identical ~8.0 plateaus: one is your password-protected backup, one is a crypted payload. Entropy cannot tell them apart. Only context (you made the backup; you didn't make the payload) distinguishes them.
Both files: ~7.99, amber, threatDetected true Entropy is identical because both are encrypted. The tool cannot classify intent. Use source/context + magic bytes.
A photo (JPEG) reads ~7.1 — borderline
A JPEG sits around 7.0-7.3, sometimes nudging chunks over 7.5. A modest high-entropy percentage that does NOT exceed 50% leaves threatDetected false. This is normal lossy-image entropy, not a payload.
Most chunks: ~7.1 A few chunks: >= 7.5 (busy/noisy image regions) Percentage: ~20% -> not amber, threatDetected false Verdict: ordinary photo. Some high chunks are expected.
Edge cases and what actually happens
There is no average score displayed
CorrectionThe UI does not show an average entropy. The two figures are the high-entropy chunk count/percentage and the footer's Max (single highest chunk). If you need a mean, average the per-chunk values yourself — the tool deliberately profiles per-window rather than collapsing to one average.
Media and documents fire the amber flag
ExpectedMP3, JPEG, MP4, ZIP, and Office documents (ZIP containers) routinely exceed 50% high-entropy chunks and turn the readout amber. This is normal for compressed formats and is not a malware indicator on its own.
Encryption and compression are indistinguishable
ExpectedBoth push entropy to the 7.5-8.0 band. The analyzer measures randomness, not meaning, so it cannot separate an AES blob from a ZIP body. Pair it with a header check for context — that is the only way to tell them apart.
Only the first dropped file is charted
By designThe drop zone accepts multiple files, but the entropy view processes files[0] only. There is no per-file batch chart. Drop one file per run; to compare two files, run them separately.
Tiny file gives a coarse percentage
Low confidenceA few-hundred-byte file is one or two chunks, so the high-entropy percentage jumps in big steps (one chunk can be 50% or 100%) and individual chunk values are noisy. Treat sub-kilobyte readings as indicative, not precise.
File too big for your tier
RejectedOver the cap the tool throws File "name" is N — exceeds the M limit for your plan before charting. Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. Upgrade or use a smaller slice.
Padding shows up as entropy 0
PreservedRuns of identical bytes (null padding, 0xFF fill) read 0.0 and appear as deep valleys. These are real and often mark boundaries between regions — the tool reports them faithfully.
Steganography rarely trips the flag
Hint onlyLSB steganography elevates carrier entropy only slightly, usually staying under 7.5, so the amber flag often will not fire. Entropy is a weak hint here; use steganography-decoder to actually extract hidden data.
No file dropped
ErrorAn empty run throws No file provided. Entropy analysis needs a binary buffer; there is no text-paste mode (unlike the password auditor, which scores a pasted string).
High entropy is not proof of anything malicious
Common misconceptionA reading near 8.0 only means the bytes are uniformly distributed — which describes encrypted backups, media, archives, and random keys as much as malware. The amber flag is a triage cue to look closer, never a verdict.
Frequently asked questions
Why does my MP3 show 7.8 bits/byte?
Because MP3 (and AAC, FLAC) use Huffman and entropy coding that produce near-maximal byte randomness — the same band as ciphertext. High entropy is normal and expected for compressed media. The amber flag firing on your music file is not a malware signal; it just means the bytes are highly random.
What entropy reading should concern me?
Context decides. A .exe sitting above 7.5 across the whole file is unusual — most unpacked binaries average 5.5-6.5 — and worth a header check. A .txt that climbs above ~6.0 is also odd. But the same high reading on a ZIP, MP4, or DOCX is completely normal because those formats are compressed.
Can the analyzer process files larger than 500 MB?
Only on the Developer tier, which allows up to 2 GB. The real limits are: Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. The whole file is read into a browser buffer and then chunked; there is no streaming, so a file over your tier cap is rejected with a plan-limit error before any analysis.
Does high entropy prove encryption, or just compression?
Neither on its own. Entropy cannot distinguish AES ciphertext from zlib/DEFLATE output — both read near-random in the 7.5-8.0 band. Use magic-byte-validator to check the header and read the entropy alongside it for context. Entropy measures randomness, not what the bytes mean.
Does the analyzer show an average entropy score?
No — this is a common misconception. The readout shows the count and percentage of high-entropy chunks (>=7.5), and the footer shows the single highest chunk as Max: X.XX bits/byte. There is no average displayed. If you want a mean, average the per-chunk values yourself.
What is the amber line on the chart?
A dashed reference line at 7.5 bits/byte — the high-entropy boundary. Any chunk at or above it is counted toward highEntropyChunks. When more than half the file's chunks cross it, the readout percentage also turns amber, indicating the file-level threatDetected condition.
Does my file get uploaded anywhere?
No. The analyzer reads your file into local browser memory and computes entropy in the tab — the bytes never leave your machine. No account is needed for the free tier. This is exactly what you want when checking a file you do not want to share with any server.
Why did only one chart appear when I dropped several files?
The entropy view analyzes the first file only, even though the drop area accepts multiple files. There is no batch overlay. Drop one file per run; to compare files, run them in separate passes and read the charts side by side.
What does the Max value in the footer mean?
It is the single highest chunk entropy in the file, shown as Max: X.XX bits/byte. It tells you the most extreme window, which is handy for spotting one embedded high-entropy region even when the overall percentage is low. It is not a file average.
My photo shows some high chunks but no amber flag — why?
JPEGs sit around 7.0-7.3 and busy regions can push individual chunks over 7.5, so you see some high-entropy chunks. But if they stay under 50% of the file, threatDetected is false and the percentage is not amber. Some high chunks in a photo are normal.
Can entropy detect steganography?
Only weakly. LSB steganography raises carrier entropy slightly but usually does not cross 7.5, so the amber flag often will not fire. Treat entropy as a faint hint at best — to actually extract hidden data from a PNG or BMP, use steganography-decoder.
What does a reading near 0 mean?
It means a run of identical bytes — typically null or 0xFF padding — where there is no uncertainty, so entropy is 0.0. These show up as deep valleys on the curve and often mark the boundary between two regions of a file.
Can I run the analyzer from a script or API?
Yes. GET /api/v1/tools/entropy-analyzer returns the schema (it has no options), and the paired @jadapps/runner runs the same computation locally, returning the chunks array, highEntropyChunks, and total. Your file never reaches JAD servers — the runner processes it on your own machine.
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.