> ssl | certificate | decoder <
// Decode SSL/PEM certificates and inspect their full X.509 contents in your browser
Issuer & Subject
Drill into the certificate authority that signed your cert and the entity it was issued to, including CN, O, OU, C, ST, and L fields.
Validity Countdown
See Not Before / Not After dates plus a clear days-remaining counter so you never get caught by a surprise SSL expiration.
Key & Signature
Reveals public key algorithm and size (RSA/ECDSA), signature algorithm, serial number, and the full SAN list for multi-domain certs.
// ABOUT SSL CERTIFICATES
How Decoding Works:
A PEM certificate is a Base64-encoded DER blob wrapped between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers. The DER payload is an ASN.1 structure defined by RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile), the same standard that underpins TLS 1.3 (RFC 8446). This tool strips the markers, Base64-decodes the body, and walks the ASN.1 tree with PKI.js to extract every field.
Example:
-----BEGIN CERTIFICATE----- MIID... -----END CERTIFICATE----- decodes into Issuer (CA), Subject (CN=example.com), validity dates, and SAN list.
Common Use Cases:
- >Verify a cert before deploying to production
- >Diagnose SSL handshake failures
- >Audit expiration dates across a fleet of services
- >Confirm SAN entries match your domain list
- >Inspect a CA-issued cert before renewal
>> frequently asked questions
Q: What is a PEM certificate?
A: PEM (Privacy-Enhanced Mail) is a text format that wraps a Base64-encoded DER X.509 certificate inside -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- markers. It is the most common format served by web servers like nginx and Apache, generated by ACME clients such as Certbot, and issued by certificate authorities. The underlying ASN.1 structure is defined by RFC 5280, which governs every field this decoder displays.
Q: Is my certificate uploaded to a server?
A: No. Parsing happens entirely in your browser via PKI.js loaded from a CDN. The PEM text never leaves your machine, which makes the tool safe for inspecting internal or pre-production certs, intermediate CA bundles, and even leaked certificates you are investigating, without ever exposing the contents to a third-party service or having to trust a remote API endpoint.
Q: What is a SAN (Subject Alternative Name)?
A: SAN is an X.509 extension defined in RFC 5280 that lists every additional hostname, IP, or URI a certificate is valid for. Modern browsers (Chrome since version 58) completely ignore the legacy Common Name field and rely entirely on SANs, so a missing or wrong SAN entry is the most common cause of the NET::ERR_CERT_COMMON_NAME_INVALID error you may see in browser DevTools.
Q: Can I decode a .crt or .cer file?
A: If the file is already in PEM (text) form, just open it in any editor and paste its contents into the input above. If it is binary DER, first convert it with `openssl x509 -inform der -in cert.cer -out cert.pem`, or run `base64 cert.cer` and wrap the output between the BEGIN/END CERTIFICATE markers manually. The decoder will then handle it the same as any other PEM.
Q: How is days-remaining calculated?
A: We take the certificate's notAfter timestamp from the validity field and subtract the current date in your browser's local time zone. A negative number means the certificate is already expired and any TLS handshake against it will fail. Most certificate authorities and operations teams recommend renewing at least 30 days before expiry to leave room for staged rollouts.