X.509 Certificate Decoder

Paste a PEM-encoded X.509 certificate and read everything inside it: subject and issuer, the validity window, the serial number, the public key type and size, the Subject Alternative Names, key-usage extensions, and the SHA-1 and SHA-256 fingerprints. The certificate is parsed locally with a built-in ASN.1/DER reader — nothing is uploaded, so it is safe for internal and client certificates.

How to use the X.509 Certificate Decoder

Paste a certificate in PEM form — the block between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- — and click decode. You can get this from a site with openssl s_client -connect host:443, from a .crt or .pem file, or from a certificate authority's download. If you paste a full chain, the first certificate is decoded.

The result lists the identity fields, validity dates with a clear expired or valid status, the public-key algorithm and size, every Subject Alternative Name (the hostnames the certificate actually covers), the key-usage and extended-key-usage extensions, and the SHA-1 and SHA-256 fingerprints used to identify or pin a certificate. All of this is computed in your browser; the certificate text is never sent anywhere.

What is inside an X.509 certificate

An X.509 certificate is the data structure behind TLS/SSL, code signing, and client authentication. At its core it binds a public key to an identity — a hostname, organisation, or person — and that binding is vouched for by a certificate authority that signs the whole thing. A browser trusts a website's certificate because it chains up to a CA the browser already trusts, and because the signature proves the contents were not altered.

The certificate is encoded in ASN.1 DER, a compact binary format, and usually wrapped in base64 with PEM header lines for transport. Inside, the to-be-signed portion holds the version, a unique serial number, the signature algorithm, the issuer (the CA), the validity period as not-before and not-after timestamps, the subject, and the subject's public key with its algorithm and size. After that comes a list of extensions and finally the CA's signature over everything above.

The extensions carry most of the operational meaning. Subject Alternative Name lists the hostnames or IPs the certificate is valid for — modern clients ignore the legacy common name and check SANs only. Basic Constraints says whether the certificate may act as a CA. Key Usage and Extended Key Usage restrict what the key may do — server authentication, client authentication, code signing, and so on. A fingerprint is simply a hash of the entire certificate; it is not stored inside but is computed on demand to identify a specific certificate or to pin it. This decoder reads all of these fields directly from the DER so you can verify a certificate without trusting an online service.

Common use cases

  • Checking expiry. Confirm a certificate's not-after date before it causes an outage.
  • Verifying coverage. See exactly which hostnames the SAN list includes.
  • Debugging TLS. Inspect the issuer, key type, and extensions of a certificate served by a host.
  • Pinning and identification. Read the SHA-256 fingerprint to pin or compare a certificate.

Frequently asked questions

Is my certificate uploaded?
No. The certificate is decoded entirely in your browser by a built-in ASN.1/DER parser, and the fingerprints are computed with the Web Crypto API locally. Nothing is sent to a server, so it is safe for internal CA and client certificates.

What certificate format does it accept?
PEM — the base64 block between BEGIN and END CERTIFICATE lines. If you have a binary DER (.der or .cer) file, convert it first with openssl x509 -inform der -in cert.der -out cert.pem, or paste the base64 if you have it.

Why does it show SANs separately from the common name?
Because modern browsers validate hostnames against the Subject Alternative Name extension and ignore the legacy common name entirely. A certificate without a matching SAN entry is rejected even if its CN matches, so the SAN list is what actually determines coverage.

Does it verify the certificate chain or signature?
No. It decodes and displays the contents of a single certificate. It does not check that the signature is valid, that the issuer is trusted, or that the chain is complete — that requires the issuer certificates and is what your TLS client does at connection time.

What are the fingerprints for?
A fingerprint is a hash of the whole certificate, used to identify or pin it. The SHA-256 fingerprint is the modern standard; SHA-1 is shown for compatibility with older tools. Two certificates are identical only if their fingerprints match.