/

SSL Certificate Decoder

Processed Client Side

Paste a PEM-encoded X.509 certificate to parse every field — subject, issuer, validity dates, serial number, and Subject Alternative Names. Runs entirely in your browser.

PEM certificate
Length: 0Lines: 1Size: 0 BytesCursor: 1:1
Decoded fields
Paste a certificate and click Decode.

Bookmark this tool now — skip the search next time you need it.

About SSL Certificate Decoder

This tool runs entirely in your browser. Whatever you paste is processed on your own device and is never uploaded, logged, or sent to any server.

Paste a PEM-encoded X.509 certificate and read what is actually inside it: who it was issued to and by, the validity window, the serial number, the signature and public key algorithms, and the full list of Subject Alternative Names. That last field is usually the answer you are looking for — modern browsers ignore the Common Name entirely and match the hostname against the SAN list, so a certificate that looks correct but throws a name-mismatch error is almost always missing the hostname there. Decoding is local, which means you can safely inspect an internal certificate without handing it to a web service.

Key features

  • Full X.509 parsing of PEM-encoded certificates
  • Subject and issuer distinguished names, with OIDs resolved to readable field names
  • Validity window with both the not-before and not-after dates
  • Serial number, certificate version, signature algorithm, and public key algorithm
  • Complete Subject Alternative Name list, covering DNS names, IP addresses, email addresses, and URIs
  • Copyable summary of the decoded fields
  • Clear errors for malformed or non-PEM input
  • Runs entirely in your browser — internal and pre-production certificates are never uploaded

How to use it

  1. Paste the certificate including the BEGIN and END CERTIFICATE lines.
  2. Read the subject and issuer to confirm what it covers and who signed it.
  3. Check the validity dates against today.
  4. Read the Subject Alternative Names — that is the list browsers actually match against.

Tips & common mistakes

  • Check the SAN list first for a name-mismatch error. Browsers stopped honouring the Common Name years ago, so a hostname missing from SAN fails no matter what the subject says.
  • A wildcard entry such as *.example.com covers one label only. It matches api.example.com but not deep.api.example.com, which surprises people regularly.
  • This decodes a single certificate. A server usually sends a chain, and an incomplete chain is the other classic cause of trust failures — decode each certificate in turn to check the issuer of one matches the subject of the next.
  • Fetch a live certificate with openssl s_client -connect host:443 -showcerts and paste what it prints between the BEGIN and END lines.
  • Decoding shows you what a certificate claims; it does not verify that a trusted authority signed it or that it matches a live connection. Only a real TLS handshake proves that.
  • Certificates and private keys are different files. A block beginning BEGIN PRIVATE KEY is not a certificate, and should not be pasted anywhere.
  • Diary the not-after date. Expired certificates remain one of the most common causes of avoidable production outages.
  • Need a fresh key pair rather than inspecting an existing certificate? Generate one with the RSA Key Generator.

Related tools

Browse all 8 Security tools

Frequently asked questions

10

Paste the full PEM block — including the BEGIN and END CERTIFICATE lines — and click Decode. The tool parses the X.509 structure and shows the subject, issuer, validity dates, serial, and Subject Alternative Names.

No. The certificate is parsed entirely in your browser by decoding its ASN.1 structure in JavaScript. Nothing is sent anywhere, so it is safe to decode internal certificates.

The decoder compares the notBefore and notAfter dates to your current time and shows a coloured badge: valid with days remaining, not yet valid, or expired.

SANs are the list of hostnames, IPs, or emails a certificate is valid for. Modern browsers ignore the Common Name and rely entirely on the SAN list, so it is the field that really determines coverage.

No. It reads and displays the fields of a single certificate but does not validate the chain of trust back to a root CA or check revocation status.

Check the Subject Alternative Names. Browsers stopped honouring the Common Name years ago and match the hostname against the SAN list only.

Only one label deep. *.example.com matches api.example.com but not deep.api.example.com, which catches people out regularly.

Run openssl s_client -connect host:443 -showcerts and paste what it prints between the BEGIN and END CERTIFICATE lines.

No. It shows what the certificate claims. It does not verify that a trusted authority signed it or that it matches a live connection — only a real TLS handshake does that.

Often an incomplete chain. Decode each certificate the server sends and confirm the issuer of one matches the subject of the next, all the way to a trusted root.