PEM/CSR Decoder
Decode an X.509 certificate or CSR (PEM) and inspect subject, validity, keys and extensions.
The pasted certificate or CSR is decoded entirely in your browser, via the Web Crypto API — no byte is sent to any server, not even Nexinon's. Unlike the Digital Certificate Verifier, this tool never reads or processes any private key: an X.509 certificate and a CSR (Certificate Signing Request) both carry only public data, even when the CSR proves possession of a private key through a signature.
What PEM is
PEM (Privacy-Enhanced Mail, RFC 7468) is the text format used to carry cryptographic data — certificates, CSRs, keys — as Base64 between a readable header and footer ("-----BEGIN ...-----"/"-----END ...-----"). It's just a text wrapper: the actual content, decoded from Base64, is a binary ASN.1/DER structure. The header says what's wrapped inside — exactly what this tool reads to figure out on its own whether the pasted text is a certificate or a CSR, without ever asking.
X.509 certificate vs. CSR: what's the difference
An X.509 certificate has already been issued by a certificate authority (CA) — it has an issuer, a validity period, and the issuer's signature vouching (as far as the trust chain allows) that the data belongs to whoever it claims to. A CSR (Certificate Signing Request, PKCS#10) is the request that comes BEFORE that: the requester generates a key pair, builds a CSR with the desired data for the final certificate plus the PUBLIC key, signs the CSR itself with the matching PRIVATE key (proving possession) and sends it to a CA to sign back. That's why a CSR never has a validity period or an issuer — those only exist once the CA actually issues the certificate.
SANs (Subject Alternative Names)
SANs are the real list of domains (or emails, IPs) a certificate covers — modern browsers ignore the "Name (CN)" field for site validation and only look at the SANs, even when the CN is also repeated there. In a CSR, the SANs are the domains the requester is ASKING the certificate to cover; the CA can issue with exactly those SANs, with fewer, or refuse — checking that a freshly generated CSR asks for exactly the right domains before sending it to the CA is this tool's most common real use.
Key Usage vs. Extended Key Usage
Both limit what the certificate's key can be used for, but at different levels. Key Usage (RFC 5280) is older and more generic — basic cryptographic operations, like "sign data" or "encipher a session key". Extended Key Usage is more specific about PURPOSE — "authenticate a TLS server", "sign code", "protect email" — and is what the browser actually checks to decide whether to accept a certificate on an HTTPS connection, for example. A typical server certificate has both: generic Key Usage ("digital signature", "key encipherment") and specific Extended Key Usage ("server authentication").
Frequently asked questions
Because they read different things. The Digital Certificate Verifier opens a password-protected .pfx/.p12 file, which bundles a certificate AND the matching private key — a much more sensitive kind of data. This decoder reads public PEM text (certificate or CSR), with no password and no private key involved whatsoever. A CSR, on top of that, isn't even a certificate yet — it's just the request.
No, never. Neither an X.509 certificate nor a CSR contains the private key — both carry only the matching PUBLIC key. If you paste something starting with "-----BEGIN PRIVATE KEY-----" (or variations), the tool refuses and warns instead of trying to process it.
Every CSR is signed by the requester's own private key, over the CSR's own data — that's how it mathematically proves whoever generated the request really holds the private key matching the public key it's asking to be certified. "Valid" here only confirms that proof of possession; it doesn't confirm any identity (that's the certificate authority's job, afterwards).
Checking revocation (CRL/OCSP) or validating the trust chain up to a trusted root requires querying an external server over the internet — which contradicts this tool's 100% local guarantee specifically for that check. To inspect a live domain's certificate, including that kind of check, use the SSL/TLS Checker.
No — not in the browser's localStorage, not on any server. As soon as you leave the page or clear the text, everything is discarded from memory.
Because those fields are optional in a CSR — they live inside an attribute ("requested extensions") that the tool used to generate the CSR may or may not include. A plain `openssl req` without `-addext`/a config file, for example, generates a CSR with only the subject data and the public key, no requested extensions — the tool shows exactly what's there, never invents an empty field.
Yes — if the public certificate (without the private key) has the technical fields ICP-Brasil uses to embed a CPF/CNPJ, the tool detects and shows it, same as the Digital Certificate Verifier. It's a rare case for this tool specifically (the typical PEM/CSR use case is server/SSL, not a Brazilian document), but the support comes for free from the same shared field-reading engine.
Nexinon Principles
Privacy
Your data never leaves your browser.No account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.