SSL Certificate Decoder (X.509)
Paste a PEM-format SSL/TLS certificate to instantly decode its subject, issuer, validity period, SAN, serial number, public key algorithm, and SHA-1/SHA-256 fingerprints. Free tool that also works offline with self-signed and internal CA certificates.
What is the SSL Certificate Decoder?
The SSL Certificate Decoder is a free tool that reads a PEM-format SSL/TLS certificate you paste in and lists out its subject, issuer, validity period, SAN entries, serial number, public key algorithm, signature algorithm, and fingerprints. Parsing the underlying ASN.1 DER binary structure happens on the server, so anyone can inspect the contents of a certificate without needing the OpenSSL command line or any special software.
Unlike a live SSL checker (which connects to a public domain over the internet and fetches the certificate through an actual TLS handshake), this tool decodes whatever PEM text you paste directly. That means it can also inspect certificates a live checker simply cannot reach: certificates not yet deployed to production, self-signed or internal CA certificates on a private network, and certificate files you already have saved locally.
How to use the SSL Certificate Decoder
- Paste your PEM certificate Paste text starting with "-----BEGIN CERTIFICATE-----" directly into the text box.
- Multiple certificates are supported Paste a full chain (leaf plus intermediate certificates) and each block is detected automatically.
- Click "Decode" Check the detected certificate count, then click the button to parse them on the server.
- Review the results Subject, issuer, validity period, SAN, fingerprints, and more are listed for each certificate.
Tips for getting more out of it
- You can paste an entire certificate chain (server certificate plus intermediate CA certificates) at once — each block is split and decoded separately.
- Compare the SHA-256 fingerprint shown here against the value published by the certificate authority or vendor to confirm the certificate has not been swapped or tampered with.
- A certificate whose Subject and Issuer are identical is self-signed, and is flagged with a dedicated badge in the results.
- Click "Load sample certificate" before pasting your own to see exactly what the output looks like.
- Before switching a multi-domain certificate into production, always confirm every required hostname is listed under SAN.
When to use this tool
Diagnosing certificate expiry errors
When a browser shows "your connection is not private" for an expired certificate, check the exact validTo timestamp directly.
Verifying SAN entries before go-live
Before cutting over a multi-domain certificate, confirm every hostname you need is actually listed in the SAN extension.
Auditing key strength
During a security review, confirm the public key algorithm and length — for example RSA 2048-bit or higher, or which EC curve is used.
Inspecting internal or self-signed certificates
Decode certificates from internal systems or private CAs that a domain-based live checker has no way to reach.
Glossary
- PEM
- A text format that wraps Base64-encoded DER data between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" lines. It is the most common way certificates are stored and exchanged.
- X.509
- The international standard defining the structure of public key certificates. It underlies not just TLS/SSL but also S/MIME and code signing.
- ASN.1 / DER
- The binary encoding rules that strictly define the certificate's internal structure. PEM is simply this DER data encoded as Base64 text.
- SAN (Subject Alternative Name)
- An extension listing the additional hostnames or IP addresses a certificate is valid for. It is required for any certificate covering multiple domains.
- Fingerprint
- A hash of the entire certificate, used to verify that a certificate has not been swapped or tampered with.
- Self-signed certificate
- A certificate whose Issuer and Subject are identical, meaning it has not been verified by a third-party certificate authority (CA).
Frequently Asked Questions
Side Note — Why does a certificate file look like unreadable gibberish?
Open a certificate file and you will usually find a block of dense, unreadable text starting with "-----BEGIN CERTIFICATE-----". That format is called PEM (Privacy-Enhanced Mail), and underneath it is nothing more than DER-encoded binary data — a structure defined by a notation called ASN.1 — wrapped in Base64 so it can travel safely through email systems and plain text files. In other words, PEM is just DER wearing a different outfit; the actual content is strictly defined as a series of ASN.1 TLV (tag, length, value) elements, and this tool's job is to decode that binary structure into something a human can actually read.
The name "X.509" itself has an unexpected history. It was originally defined by the ITU-T (International Telecommunication Union) in 1988 as part of the X.500 directory services standard, long before the modern web existed. It was later adapted for internet use by the IETF as RFC 2459 in 1999, and today RFC 5280 is the current specification. Certificates come in versions v1, v2, and v3 — and extension fields such as SAN (Subject Alternative Name) only became available starting with v3. Virtually every TLS certificate issued today is v3, and this tool assumes v3-style extensions when decoding.
You will often see both a SHA-1 and a SHA-256 fingerprint listed side by side for the same certificate. SHA-1 has been deprecated as a signing algorithm ever since practical collision attacks were demonstrated against it, but it still shows up as a fingerprint for identifying a certificate uniquely, mostly for compatibility with older tooling — which is why this tool displays both. For any new verification work, it is best to prioritize the SHA-256 value instead.