How to read signing info vs jarsigner, apksigner & openssl
- Step 1Decide detection vs verification — If you only need to know "signed or not, what files", use Read Signing Info. If you need a valid/invalid verdict or signer identity, reach for
apksigner verifyorjarsigner -verify. - Step 2Match the tool to the archive — JAR / library →
jarsigner. APK →apksigner. Raw PKCS#7 / DER blob →openssl. Read Signing Info covers all of these for the presence check, but none for verification. - Step 3Check install constraints — On a machine without the JDK or Android SDK, Read Signing Info needs nothing but a browser and a Pro login. The CLIs need their toolchains installed and on PATH.
- Step 4Respect the size ceiling — Read Signing Info caps at 500 MB (Pro) / 2 GB (higher). For a multi-GB fat archive the CLI has no such ceiling.
- Step 5Read the right output — Read Signing Info emits
<name>-signing.jsonwith afindingslist.apksignerprints certificate fingerprints;jarsignerprints "jar verified". They are not interchangeable outputs. - Step 6Combine them in a pipeline — Use the browser tool for an ad-hoc triage check, then gate releases on
apksigner verifyin CI so a real signature failure can never ship.
Detection vs verification: who does what
The defining difference. Read Signing Info stops at detection by design — the implementation never parses certificates or checks digests.
| Capability | Read Signing Info | jarsigner | apksigner | openssl |
|---|---|---|---|---|
| Detect JAR signing files | Yes (lists .RSA/.DSA/.EC/.SF) | Yes | Yes (v1) | No |
| Detect APK Signing Block | Yes (magic bytes) | No | Yes | No |
| Verify digests / validity | No | Yes | Yes | Partial (manual) |
| Print signer certificate | No | Yes (-certs) | Yes (--print-certs) | Yes |
| Distinguish APK v2 vs v3 | No (reports "v2/v3") | No | Yes | No |
| Parse ZIP 0x0065 / PKCS#7 | No | No | No | Yes |
Practical trade-offs
When each path wins. Read Signing Info requires a Pro tier; CLIs require their toolchains installed.
| Factor | Read Signing Info (browser) | CLI (jarsigner/apksigner/openssl) |
|---|---|---|
| Install required | None — browser + Pro login | JDK / Android SDK / openssl on PATH |
| Privacy | File never leaves the device | Local — also private |
| Max input size | 500 MB Pro / 2 GB higher | No practical ceiling |
| Scriptable in CI | No (UI, one file at a time) | Yes |
| Answers "is it valid?" | No — presence only | Yes |
| Time to first answer | Seconds, no setup | Setup once, then seconds |
Cookbook
The same APK, asked the same question by each tool — so you can see exactly where the browser answer ends and the CLI answer begins.
Read Signing Info: presence check
The browser answer. Fast, no install, but it stops at "a block is present". It cannot tell you the signer or whether the signature is valid.
app-release-signing.json
{
"filename": "app-release.apk",
"findings": [
"Found META-INF/MANIFEST.MF — JAR-style archive.",
"Signing files: META-INF/CERT.SF, META-INF/CERT.RSA",
"APK Signing Block detected (Android v2/v3 signature)."
]
}apksigner: the full verdict
What the CLI adds: a valid/invalid verdict, the exact scheme versions, and the signer certificate fingerprint. This is the part Read Signing Info does not do.
$ apksigner verify --verbose --print-certs app-release.apk Verifies Verified using v1 scheme (JAR signing): false Verified using v2 scheme (APK Signature Scheme v2): true Verified using v3 scheme (APK Signature Scheme v3): true Signer #1 certificate SHA-256 digest: 3a1f...d2
jarsigner: verify a signed JAR
For a JAR, jarsigner checks every entry digest against the signature. Read Signing Info only lists the .SF/.RSA filenames — it never opens them.
$ jarsigner -verify -verbose -certs commons-lang3-3.14.0.jar s k 1234 Fri ... META-INF/MANIFEST.MF jar verified. The signer certificate is valid until 2027-04-01.
openssl: low-level PKCS#7
When you have a raw signature blob, openssl parses the ASN.1. Read Signing Info has no PKCS#7 parser at all, so this is strictly a CLI job.
$ openssl pkcs7 -inform DER -in META-INF/CERT.RSA -print_certs -noout subject=CN=Example Release Key, O=Example issuer=CN=Example Release Key, O=Example
When the browser check is enough
Triaging a third-party JAR you were sent. You just need to know if it claims to be signed before bothering with full verification.
Question: "Is this vendor JAR even signed?"
Read Signing Info → mystery-lib-signing.json
{
"findings": ["Found META-INF/MANIFEST.MF — JAR-style archive."]
}
Answer: manifest only, no .SF/.RSA → not signed. No CLI needed.Edge cases and what actually happens
Trusting the presence check as a verdict
MisuseA finding of "APK Signing Block detected" means a block exists, not that it is valid or from a trusted key. Never gate a release on Read Signing Info alone — use apksigner verify for the verdict.
Multi-GB fat archive
Tier limit exceededRead Signing Info caps at 500 MB (Pro) or 2 GB. A larger archive must go through the CLI, which has no such ceiling.
No JDK / SDK on the machine
CLI unavailableOn a locked-down laptop with no toolchain, the CLIs simply are not there. Read Signing Info needs only a browser and a Pro login — this is its clearest win.
Need v2-vs-v3 distinction
Use CLIRead Signing Info reports "v2/v3" generically from the magic bytes. Only apksigner verify --verbose tells you which scheme(s) actually verify.
Signer identity required
Use CLICertificate subject, issuer, and SHA-256 fingerprint come from apksigner --print-certs, jarsigner -certs, or keytool. Read Signing Info never parses certificates.
Renamed or non-ZIP container
SupportedRead Signing Info routes by magic bytes and can read 7z/rar/tar via libarchive — handy when a vendor mislabels a file. The CLIs expect the format their flags assume.
CI / automated gating
Use CLIRead Signing Info is a UI tool with no API yet. Any automated release gate must call apksigner/jarsigner in the pipeline.
Raw PKCS#7 blob, no archive
Use opensslIf you only have a .RSA / DER signature file and no container, Read Signing Info has nothing to extract. openssl pkcs7 -print_certs is the tool.
Frequently asked questions
Is Read Signing Info a replacement for apksigner?
No. It is a fast detector that complements apksigner. It tells you a signing block is present; apksigner verify tells you whether it is valid and by whom.
Why use the browser tool if the CLI does more?
Because the CLI is not always available and not always needed. For a 5-second "is this even signed?" triage on a machine with no toolchain, the browser tool wins. For a release gate, use the CLI.
Does Read Signing Info ever parse certificates?
No. The implementation only lists filenames and checks magic bytes. There is no certificate, digest, or PKCS#7 parsing anywhere in it.
Can it tell me if a signature is valid?
No. Validity requires checking digests against a trust chain, which only jarsigner -verify, apksigner verify, or manual openssl work can do.
Which is faster for one file?
Both are seconds for typical JAR/APK sizes once set up. The browser tool needs no setup; the CLI needs its toolchain installed once. For a one-off on an unprovisioned machine the browser is faster end-to-end.
Does the CLI upload my file?
No — the CLIs run locally. So does Read Signing Info (in-browser). Both are private; the difference is install footprint and depth of analysis, not privacy.
Can Read Signing Info read 7z or rar that the CLIs ignore?
It can extract 7z/rar/bz2/xz via libarchive WASM, but its signing checks are aimed at JAR/APK structures. jarsigner/apksigner expect JAR/APK specifically.
Which detects the APK v3 block — the browser or the CLI?
Both detect a v2/v3 block exists. Only apksigner distinguishes and verifies v2 vs v3 individually.
Can I script Read Signing Info like the CLI?
Not today — it is a single-file UI tool with no public API. For automation, script apksigner/jarsigner instead.
What about the ZIP 0x0065 digital-signature extra field?
Neither this tool nor the standard CLIs focus on it. Read Signing Info does not parse it at all; openssl asn1parse on the extracted blob is the manual route.
How do I combine them cleanly?
Triage with Read Signing Info, attach <name>-signing.json to the ticket, then run apksigner verify --print-certs (or jarsigner -verify) in CI as the authoritative gate.
Are the browser tool's findings trustworthy?
For presence, yes — they come from deterministic byte checks. For validity, they make no claim, so do not read a positive finding as "the signature is good".
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.