How to troubleshooting read signing info
- Step 1Check whether it is really unsigned — A "No digital signature found" result is often correct — most ZIPs are unsigned. If you expected a signature, confirm the archive type really should carry one (JAR/APK/AAR).
- Step 2Distinguish manifest from signature — If you see only "Found META-INF/MANIFEST.MF" with no "Signing files" line, the archive has a manifest but no signing files — it is not signed. That is the answer, not a bug.
- Step 3Confirm the format — Run Auto-Format Detector. A mislabelled file (a
.apkthat is actually something else) or an unrecognised format can cause extraction to fail before detection runs. - Step 4Check for encryption — Read Signing Info passes no password to the extractor. If the archive is encrypted, use Encrypted Archive Detector to confirm, then decrypt elsewhere first.
- Step 5Check size and entry caps — A file over your tier's size cap (500 MB Pro / 2 GB higher) or over the per-archive entry cap (50,000 Pro / 500,000 higher) is rejected before processing. Upgrade or trim.
- Step 6Switch to a verifier when needed — If you actually need a valid/invalid verdict or signer details, this tool cannot help — run
apksigner verify --print-certsorjarsigner -verify -certs.
Symptom → cause → fix
Diagnostic order for the failures users actually hit. The finding wording is the tool's real output.
| Symptom | Likely cause | Fix |
|---|---|---|
| "No digital signature found" on a signed JAR | Only manifest present, or extraction yielded no signing entries | Confirm .SF/.RSA exist; manifest alone is not a signature |
| Extraction fails immediately | Encrypted or corrupt archive | Encrypted Archive Detector / Corrupted ZIP Repair |
| "Tier limit exceeded" before processing | File over size cap or over entry cap | Upgrade tier or reduce the archive |
| APK reported unsigned but you expected a block | Magic missing / damaged central directory | Verify with apksigner verify; check for corruption |
| Want validity but only got presence | Tool detects, does not verify | Use apksigner / jarsigner / openssl |
| Wrong format detected | Renamed extension | Auto-Format Detector confirms true type |
Tier caps that block a run
Read Signing Info needs a Pro tier minimum. Both the size cap and the per-archive entry cap can reject a file before detection starts.
| Tier | Size cap | Entry cap | Note |
|---|---|---|---|
| Free | n/a | n/a | Tool not available — Pro minimum |
| Pro | 500 MB | 50,000 | Fits nearly all JAR/APK |
| Pro-Media | 2 GB | 500,000 | Large or entry-heavy archives |
| Developer | 2 GB | 500,000 | Same caps |
| Enterprise | unlimited | unlimited | No caps |
Cookbook
The reports behind common confusion, with what each actually means. The shape is the tool's real { filename, findings } output.
"No signature" that is actually correct
The most-reported 'bug' that is not one. A plain ZIP has no signing artifacts — the report is right. Signing is mainly a JAR/APK/AAR concern.
build-assets-signing.json
{
"filename": "build-assets.zip",
"findings": [
"No digital signature found."
]
}
Reason: plain ZIPs are unsigned. Not a failure.Manifest-only mistaken for unsigned
A JAR with build metadata but no signing files. People read "manifest found" as "signed" — it is not. The absence of a "Signing files" line is the tell.
my-lib-signing.json
{
"filename": "my-lib.jar",
"findings": [
"Found META-INF/MANIFEST.MF — JAR-style archive."
]
}
Meaning: has a manifest, NOT signed (no .SF/.RSA listed).Encrypted archive — extraction fails
Read Signing Info passes no password, so an encrypted ZIP cannot be extracted and detection never runs. Confirm encryption, then decrypt before scanning.
Drop: secured-bundle.zip (AES-encrypted entries)
Result: extraction error — entries cannot be read.
Next: Encrypted Archive Detector confirms encryption →
decrypt in your own workflow → re-run Read Signing Info.Tier / entry-cap rejection
A fat APK with too many entries is blocked before processing on Pro. The entry cap, not just size, is the limiter here.
Drop: mega-bundle.apk (62,000 entries, 410 MB) Result: "Tier limit exceeded" — over Pro's 50,000-entry cap. Fix: upgrade to Pro-Media/Developer (500,000 entries) or scan a slimmer artifact.
Right answer, wrong question
The report confirms a signing block exists, but the user wanted to know if it is valid. The tool cannot answer that — the next step is a CLI verifier.
app-signing.json
{
"findings": ["APK Signing Block detected (Android v2/v3 signature)."]
}
User wanted: "is it valid & who signed it?"
Answer requires: apksigner verify --print-certs app.apkEdge cases and what actually happens
"No digital signature found" on a plain ZIP
ExpectedMost ZIPs are unsigned, so this is the correct result, not a failure. Signing artifacts mainly appear in JAR / APK / AAR distributions.
Manifest present, no signing files
Not signedA "Found META-INF/MANIFEST.MF" line without a "Signing files" line means the archive has a manifest but is not signed. Read the absence of the signing line as the answer.
Encrypted archive
Extraction failedThe tool passes no password to the extractor, so encrypted entries cannot be read and no detection runs. Confirm with Encrypted Archive Detector and decrypt first.
Corrupt central directory
Extraction failedIf the ZIP EOCD/central directory is damaged, extraction fails and the APK-block check (read relative to the central-directory offset) cannot run. Try Corrupted ZIP Repair.
File over the size cap
Tier limit exceededPro caps at 500 MB; Pro-Media/Developer at 2 GB. A larger file is rejected before extraction. Upgrade the tier or reduce the archive.
Archive over the entry cap
Tier limit exceededThe per-archive entry cap (50,000 Pro / 500,000 higher) can reject a file even under the size cap. Entry-heavy fat archives are the usual culprit.
Renamed extension
SupportedDetection uses magic bytes, so a renamed file (a .jar that is really a tar) is routed to the right extractor. Confirm the true type with Auto-Format Detector.
Expecting a validity verdict
Out of scopeRead Signing Info never verifies. "Is the signature valid / who signed it?" needs apksigner verify --print-certs, jarsigner -verify -certs, or openssl.
APK with stripped META-INF reported unsigned
Check magicIf a v2/v3 APK reports no block, the central-directory offset or magic may be damaged. Verify with apksigner and check the file for corruption before concluding it is unsigned.
Frequently asked questions
Why does it say 'No digital signature found' on my signed JAR?
Usually because only META-INF/MANIFEST.MF is present (a manifest is not a signature) or extraction produced no META-INF/*.RSA/.DSA/.EC/.SF entries. Confirm those signing files actually exist in the archive.
Is a manifest the same as a signature?
No. Almost every JAR has META-INF/MANIFEST.MF. Signing requires the .SF + .RSA/.DSA/.EC files. A manifest-only finding means the archive is not signed.
Why does my archive fail to extract?
The two common causes are encryption (the tool passes no password) and corruption. Confirm encryption with Encrypted Archive Detector and corruption with Corrupted ZIP Repair.
What does 'Tier limit exceeded' mean?
Your file is over the size cap (500 MB Pro / 2 GB higher) or over the per-archive entry cap (50,000 Pro / 500,000 higher). Both are checked before processing. Upgrade or reduce the archive.
Why doesn't it tell me if the signature is valid?
By design — it is a detector, not a verifier. It never parses certificates or checks digests. Use apksigner verify, jarsigner -verify, or openssl for validity and signer identity.
It's stuck — is it hung?
Large 7z/rar inputs need the libarchive WASM chunk to load, which can take a moment on first run. If the page seems stale after a deploy, hard-refresh (Ctrl+Shift+R) to load the latest build.
Why was my APK reported unsigned when I know it's signed?
The APK-block check reads bytes relative to the central-directory offset. A damaged central directory or a non-standard layout can make the magic check miss. Verify with apksigner verify and check for corruption.
Can I run it on a free account?
No. Read Signing Info has a Pro minimum tier. The free tier does not include it.
Does it output a fixed or repaired archive?
No. It only reads the archive and emits a <name>-signing.json report. It never modifies, repairs, or re-emits your input — use Corrupted ZIP Repair for recovery.
Why is the report so small?
It is just a JSON findings list, not a copy of the archive. A few lines is the expected size; the Findings metric shows how many lines it produced.
The file is a renamed .rar — will it still work?
Yes for extraction (magic-byte detection routes it to libarchive WASM), but RAR is not a JAR/APK, so the signing checks will typically report no signature. Confirm the true format with Auto-Format Detector.
What if I need the signer's certificate?
This tool never reads certificates. Use apksigner verify --print-certs, jarsigner -verify -certs, or keytool -printcert to get signer details.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.