Decode and inspect SSL/x509 certificates in your browser

An x509 certificate binds a public key to an identity. It is the building block TLS/HTTPS rests on: when the browser opens https://, the server presents a certificate claiming "this public key belongs to this domain", signed by a Certificate Authority the browser trusts. The format and validation rules for the internet PKI are set out in RFC 5280. A certificate carries the version, serial number, signature algorithm, the issuer's Distinguished Name, the validity window (Not Before / Not After), the subject's Distinguished Name, the public key and a set of extensions (SAN, Key Usage, Basic Constraints and others).

The chain of trust. No browser trusts your site's certificate directly. It trusts a few hundred root CAs preinstalled in its trust store. Your certificate (the leaf, or end-entity) is signed by an intermediate CA, which is in turn signed by the root. Validation means building a path from the leaf up to a trusted root: every link must be signed by the next one. If an intermediate is missing (a common deployment mistake) the chain breaks and the browser rejects the connection even when the site certificate itself is perfect. That is why the tool lets you paste the entire chain and shows, cert by cert, who signs whom.

SAN beats Common Name. Historically the hostname lived in the Subject's Common Name (CN). Since 2017 Chromium-based browsers, and every other browser after them, ignore the CN entirely for domain matching: only the Subject Alternative Names count. A certificate with CN=example.com but without example.com in its SAN throws ERR_CERT_COMMON_NAME_INVALID. The CN is cosmetic today and usually just repeats the first SAN. When you decode a certificate to work out why a domain is not covered, look at the SAN, not the CN.

Expiry and renewal. The maximum lifetime of public TLS certificates has kept shrinking: from the old 3 years to 825 days, down to the 398 days browsers have enforced since 2020. The CA/Browser Forum has also approved a stepwise reduction toward roughly 47 days by 2029. The practical consequence is that manual renewal is no longer sustainable: teams rely on ACME and short-lived certificates (Let's Encrypt issues for 90 days, renewed automatically). Decoding the certificate before a deploy, or during an incident, is still the fastest way to read the exact Not After date and know how many days are left.

PEM, DER and fingerprints. A certificate is essentially an ASN.1 structure encoded in DER (binary). PEM is that binary in base64, wrapped between the BEGIN/END delimiters: plain ASCII text you can copy anywhere. Extensions like .crt and .cer may hold either form. The fingerprint is not a field inside the certificate: it is the hash (SHA-256, or SHA-1 for compatibility) computed over the DER bytes of the whole certificate, and it uniquely identifies a copy, for example in certificate pinning or when comparing two exports.

Decoding is not validating. This tool reads and shows what the certificate claims; it does not verify the CA signature, it does not check revocation (OCSP/CRL) and it does not confirm the chain reaches a trusted root. A certificate can decode without errors and still be rejected by the browser because it is expired, has a hostname outside its SAN, is self-signed or is missing an intermediate. Decoding gives you the facts; trust is a separate judgement that depends on the trust store and the context.

Privacy by design. No upload, no remote fetch. The PEM is converted to DER, parsed and hashed entirely in your browser via WebCrypto. The domain the certificate belongs to is never contacted by our server. It is the right tool to inspect certificates of internal systems, staging environments unreachable from outside, intranet devices or certificates exported from an HSM that you do not want leaving your network.