X.509 · Certificate Decoder

How to decode an SSL/TLS certificate (free)

1. Paste one or more PEM blocks into the box, or drop a .pem, .crt, .cer or .der file on the drop zone.
2. Each certificate is decoded instantly into a card with its subject, issuer, validity, SANs, key and extensions.
3. If you pasted a chain, the summary above the cards tells you whether the order is correct and whether each signature checks out.
4. Use Copy PEM or Download DER on any card to convert it to the other format.

What the fields mean

The subject is who the certificate is for and the issuer is the CA that signed it, both written as distinguished names (CN common name, O organization, OU unit, C country, ST state, L locality). Modern browsers ignore the CN for hostnames and only look at the Subject Alternative Names: DNS names, IP addresses, URIs and email addresses the certificate is valid for. Validity is the notBefore/notAfter window, shown here in UTC and in your local time with a badge for valid, expired or not yet valid. Key usage and extended key usage restrict what the key may do (sign, encipher, TLS server or client auth, code signing). Basic constraints say whether the certificate is a CA and how many intermediates may follow it. The SKI and AKI key identifiers link a certificate to its issuer, and the CRL and AIA URLs tell clients where to check revocation and fetch the issuer.

Checking a certificate chain

A server should send its leaf certificate first, followed by each intermediate in order, with every certificate's issuer equal to the next one's subject. A wrong order or a missing intermediate is a common cause of "unable to get local issuer certificate" errors on some clients while browsers seem fine. When you paste several certificates, this tool compares each issuer to the next subject, flags an out-of-order chain, suggests the correct order, and tries to verify each signature using the next certificate's public key with Web Crypto. It does not check revocation, trust stores, name constraints or hostnames, so treat it as a sanity check rather than a full validation.

PEM vs. DER, and fingerprints

DER is the binary ASN.1 encoding of a certificate; PEM is the same bytes in base64 between -----BEGIN CERTIFICATE----- lines. Extensions like .crt and .cer can hold either, which is why this tool looks at the file's content rather than its name. The SHA-1 and SHA-256 fingerprints are hashes of the DER bytes, so they are identical whichever format you start from and match the output of openssl x509 -fingerprint -sha256. Use them to pin a certificate or confirm two files are the same certificate.

Is my certificate private?

Yes. Parsing uses the open-source PKI.js and ASN1.js libraries loaded from this site, and hashing uses your browser's Web Crypto API. Nothing is uploaded — you can check the network tab, and it works offline once loaded.

Can it read certificate signing requests?

Yes. Paste a BEGIN CERTIFICATE REQUEST block to see the requested subject, public key, signature algorithm and requested extensions such as SANs, plus whether the CSR's self-signature verifies.

Does it validate the whole chain?

Only partly: issuer/subject order and signatures between the certificates you paste. It does not check revocation (OCSP/CRL), trust stores, name constraints or hostname matching.

How are fingerprints calculated?

As SHA-1 and SHA-256 hashes of the exact DER bytes, shown as colon-separated hex — the same values openssl and browsers show.

Should I paste my private key?

No, and you don't need to. If a private key block is pasted, it is ignored and you get a warning.