Paste any PEM certificate into the Certificate Decoder and get subject, issuer, validity, public key, extensions, and SHA-256/SHA-1 fingerprints in one pass.
Why read the certificate instead of trusting the lock icon
A TLS server presents its certificate on every handshake, and the browser checks it before you see the padlock. When a connection fails with an expiry error, a hostname mismatch, or a self-signed warning, the certificate itself is the first place to look.
`openssl x509 -in cert.pem -text -noout` prints the same fields this page decodes: subject, issuer, validity period, serial number, signature algorithm, public key, and extensions. Understanding those fields turns a wall of base64 into an actionable diagnosis.
openssl x509 -in cert.pem -text -nooutopenssl x509 -in cert.pem -fingerprint -sha256 -nooutPEM and DER: the two formats you will meet
DER is the binary encoding of the certificate structure defined in RFC 5280. PEM (RFC 7468) is that same DER wrapped in base64 between `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` lines so it can travel through text channels.
Servers usually deliver PEM files, but some APIs export DER directly. The decoder accepts both: paste the PEM block or the base64-encoded DER body and the fields are extracted in the browser.
The fields that answer most debugging questions
Subject and issuer name who the certificate belongs to and who signed it. A self-signed cert has the same subject and issuer, which is exactly what you see in the browser warning.
Validity gives Not Before and Not After. Expired certificates cause far more TLS failures than most developers expect, and future-dated certificates appear when a machine clock is wrong.
Serial number and signature algorithm identify the certificate and the crypto used to sign it. Public key shows the algorithm and size — RSA 2048, for example — which matters when you compare certificates before and after a renewal.
You can inspect a public key or hash files locally with the Hash Generator to cross-check fingerprints against published values.
Fingerprints: what they do and what they do not do
A fingerprint is a hash of the certificate's DER bytes. Two certificates with different bytes produce different SHA-256 fingerprints, which makes fingerprints useful for confirming you are looking at the expected certificate.
Vendors sometimes publish the SHA-256 fingerprint of their certificate or package. You can reproduce it locally:
openssl x509 -in cert.pem -fingerprint -sha256 -noout
Compare that output with the SHA-256 value shown by the decoder. A match confirms the exact bytes; it does not prove the certificate is trustworthy — trust comes from the chain, not from a fingerprint.
SAN and extensions: what the certificate is allowed to do
Subject Alternative Name (SAN) lists the domains and identities the certificate covers. A hostname mismatch happens when the URL's domain is not in this list, even if the certificate is valid and unexpired.
Key Usage and Extended Key Usage restrict how the key may be used: signing, key encipherment, server authentication, or client authentication. A certificate with the right fields but the wrong usage will fail in specific clients.
Basic Constraints tells you whether a certificate is a CA. Intermediates and roots carry CA:TRUE; leaf certificates normally carry CA:FALSE.
Why parse locally instead of pasting into an online service
A public certificate is not secret, but the habit of pasting certificate material into random web forms is worth breaking. The same tool that decodes a certificate often also claims to handle private keys, and one wrong paste is all it takes.
The decoder runs entirely in the browser: no network request is made while parsing. Verify it yourself by opening DevTools → Network and watching the request log while pasting a certificate — nothing appears because nothing leaves your device.
The same principle applies to the JWT Decoder: tokens and keys stay local, and the output is meant for your eyes only.
FAQ
Q.Is my certificate uploaded when I decode it?
A.No. Parsing and fingerprinting run locally in your browser. Open DevTools → Network and paste a certificate to see that no request is emitted.
Q.I pasted a full certificate chain. Why do I only see one certificate?
A.The decoder shows the first certificate in the input and notes when more blocks are present. For chain inspection, decode each PEM block separately or use openssl to view the full chain.
Q.What is the difference between SHA-256 and SHA-1 fingerprints?
A.Both are hashes of the certificate's DER bytes. SHA-1 is deprecated for most purposes, so compare SHA-256 fingerprints when a vendor publishes them and treat SHA-1 only as a legacy reference.
Q.Can I decode a certificate in DER format?
A.Yes. Paste the base64-encoded DER body directly, or wrap it in PEM headers. The decoder detects either form automatically.
References
The fields and structure above follow these standards:
- RFC 5280 – Internet X.509 Public Key Infrastructure Certificate and CRL Profile: https://www.rfc-editor.org/rfc/rfc5280
- RFC 7468 – Textual Encodings of PKIX, PKCS, and CMS Structures (PEM): https://www.rfc-editor.org/rfc/rfc7468
- RFC 9325 – Recommendations for Secure Use of TLS and DTLS: https://www.rfc-editor.org/rfc/rfc9325
Decode a certificate now
Subject, issuer, validity, public key, extensions, and fingerprints — parsed locally in your browser, never uploaded.
Read the certificate before you trust the error message
Certificate errors usually come down to four fields: validity dates, subject vs. SAN, self-signed status, and the public key. Decode the PEM locally, check those fields, and compare the SHA-256 fingerprint with any published value.
Open the Certificate Decoder, paste the PEM, and read the fields yourself.