An SSL certificate decoder that works offline
This ssl certificate decoder reads an X.509 certificate and lays out every field in plain text: subject, issuer, validity dates, serial number, public key, extensions and fingerprints. Use it to confirm that a certificate covers the right hostnames before you deploy it, to find out when a certificate expires, or to understand a chain a server is sending.
What is an X.509 certificate?
An X.509 certificate binds a public key to a name. A certificate authority (CA) signs a structure containing the subject name, the key, a validity period and a list of extensions. TLS servers, code-signing tools, VPN clients and SAML identity providers all use the same format.
PEM files (.pem, often .crt) are Base64 text between BEGIN CERTIFICATE and END CERTIFICATE lines. DER files (.der, often .cer) hold the same bytes in binary. The decoder accepts both, plus raw Base64 or hex.
Example
Decoding the sample EC certificate gives a report like this (shortened):
Subject: C=US, ST=California, L=San Francisco, O=Example Inc, CN=www.example.com
Issuer: C=US, ST=California, L=San Francisco, O=Example Inc, CN=www.example.com (self-signed)
Valid from: 2026-09-25 20:20:13Z
Valid until: 2028-12-28 20:20:13Z
Status: valid (824 days left)
Signature: ecdsa-with-SHA256
Public key: EC 256 bit (prime256v1 (P-256))
Names (SAN): DNS:www.example.com, DNS:example.com, DNS:api.example.com
Fingerprints:
SHA-256: 6C:43:F6:9E:31:85:35:7E:3F:99:72:50:79:15:E9:06:…
SPKI SHA-256 (pin, Base64): +RnN6DiU20GQfUlFc8WFs8QbSuUosWM0FIl274Q0g9U=
Fields explained
- Status: compares the validity dates with your computer's clock and shows valid with the days left, EXPIRED or not yet valid.
- Names (SAN): the Subject Alternative Names. Browsers match the hostname against this list, not the Common Name, so a missing SAN is a common reason for a name mismatch error.
- Extensions: key usage, extended key usage (for example serverAuth), basic constraints (whether the certificate is a CA), key identifiers, CRL distribution points, Authority Information Access (OCSP and CA issuer URLs), policies and the number of embedded Certificate Transparency SCTs.
- Fingerprints: SHA-256 and SHA-1 over the whole certificate, plus a Base64 SHA-256 of the public key (SPKI). The SPKI hash is the value used for certificate pinning, and it stays the same when a certificate is renewed with the same key.
The JSON output holds the same data as an object, which is useful when you want to compare two certificates in a diff or process them in a script.
Decoding a certificate chain
Paste several PEM blocks at once, for example the contents of a fullchain.pem file, and each certificate is decoded under its own heading. Read the issuer of one certificate and the subject of the next to check that the chain is in order: leaf first, then each intermediate. Certificate requests in the same paste are skipped. Use the CSR decoder for those.
Common errors and fixes
- "No certificate found": the text is a key or a CSR, or the BEGIN line is missing. Copy the whole block, including both dashed lines.
- "This is not an X.509 certificate": the bytes are valid DER but hold something else. Inspect them with the ASN.1 decoder.
- Base64 errors: email clients sometimes add spaces or break lines. Line breaks are fine, but other characters inside the block are not.
To get the certificate a live server presents, run openssl s_client -connect example.com:443 -showcerts and paste the PEM blocks from the output.
Privacy
The certificate is parsed in your browser by a built-in ASN.1 reader, and fingerprints are computed with WebCrypto. Nothing is uploaded. The tool does not contact the issuing CA, so it does not check revocation or validate the chain up to a trusted root. For JWT signing certificates, pair it with the JWT verifier.