📄 Certificate Decoder
Paste an X.509 certificate below to instantly see its issuer, subject, validity dates, SAN list, key usage, and SHA-256 fingerprint — decoded entirely inside your browser, nothing uploaded.
What This Decoder Actually Shows You
An issued X.509 certificate is a DER-encoded ASN.1 structure — the same encoding family as a CSR, but a genuinely different schema, defined in RFC 5280. This tool parses that structure directly and surfaces every field worth checking by eye: who issued it, who it was issued to, exactly when it's valid, every hostname it covers, its public key, and the extensions that constrain how it may be used. Nothing is sent anywhere — parsing and the SHA-256 fingerprint calculation both happen locally using your browser's own JavaScript engine and Web Crypto API, the same engine that verifies certificates during ordinary HTTPS browsing.
Reading the Validity Period Correctly
Not Before and Not After define the window a certificate is considered valid, encoded as either UTCTime (two-digit years, used for dates before 2050) or GeneralizedTime (four-digit years) depending on when the certificate was issued. This tool decodes both formats and additionally compares Not After against the current date to flag the certificate's status directly — currently valid, not yet valid, or expired — since squinting at a raw ISO timestamp to do that mental math yourself is exactly the kind of small friction a decoder should remove. A certificate close to its Not After date but not yet expired is worth flagging for renewal regardless of what the status field says, since most CAs recommend renewing well before the actual expiry.
Issuer vs Subject: Detecting a Self-Signed Certificate
The Issuer field identifies whose private key signed this certificate; the Subject field identifies who the certificate was issued to. For a normal, CA-issued certificate, these are different entities — a public CA (or an internal corporate CA) issuing to a specific domain or device. When every field in Issuer matches every field in Subject exactly, the certificate signed itself, which is completely normal for root CA certificates (the very top of a trust chain necessarily has no one else to sign it) and for internal test certificates, but is a red flag on a public-facing production web server, since browsers won't trust a self-signed leaf certificate without the visitor manually installing it first.
Basic Constraints: Can This Certificate Sign Others?
The Basic Constraints extension's CA:TRUE or CA:FALSE value is the field that actually distinguishes a Certificate Authority certificate from an end-entity (leaf) certificate meant to sit on a specific server. A CA:TRUE certificate, often paired with a pathLenConstraint limiting how many intermediate CAs may sit beneath it, is permitted to sign other certificates. CA:FALSE, or the extension being absent entirely, means the certificate may only be used to identify the specific server or client it was issued to. Decoding a certificate you received from a vendor or a CA and finding CA:TRUE where you expected an end-entity certificate is worth investigating before deploying it anywhere — it's not the certificate type a web server's TLS configuration should be using.
Key Usage vs Extended Key Usage
These two extensions restrict different things and frequently get confused. Key Usage is a bitmask constraining the cryptographic operations the key itself may perform — digitalSignature, keyEncipherment, keyCertSign, cRLSign, and several others — enforced at the algorithm level. Extended Key Usage instead lists application-level purposes the certificate is valid for, such as TLS Server Authentication or TLS Client Authentication, identified by OID rather than bit flag. A typical web server certificate carries digitalSignature and keyEncipherment in Key Usage alongside serverAuth in Extended Key Usage; a CA certificate instead carries keyCertSign and cRLSign in Key Usage and typically no Extended Key Usage at all, since its purpose is signing certificates, not authenticating a TLS connection directly.
Public Key Algorithm & Size
The decoder identifies whether the embedded public key is RSA or ECDSA and reports the real key size — the actual bit-length of the RSA modulus, or the named curve for ECDSA (P-256 or P-384) — read directly from the certificate rather than trusted from a label. This is a genuinely useful cross-check when auditing certificates you didn't generate yourself: confirming an inherited or vendor-supplied certificate actually meets a stated minimum key size takes one paste, rather than trusting whatever a spec sheet or purchase order claims.
The SHA-256 Fingerprint, and What It's Actually For
The fingerprint shown here is a SHA-256 hash of the certificate's complete DER encoding, computed locally with crypto.subtle.digest() — the same technique browsers use internally when comparing a presented certificate against a pinned or previously-seen value. It's the standard way to confirm two certificate files are byte-for-byte identical without comparing the full PEM text character by character, and it's what certificate pinning configurations, some API client libraries, and manual "does this match what I expect" checks rely on. A fingerprint mismatch between what you expected and what a server actually presents is a meaningful signal worth investigating, not a cosmetic detail.
Certificate Decoder vs CSR Decoder: Which One Do You Need
| You Have | Use | Key Fields It Shows |
|---|---|---|
| An unsigned request, not yet issued | CSR Decoder | Requested subject, requested SAN, public key |
| A certificate already issued by a CA | Certificate Decoder (this tool) | Issuer, validity dates, actual SAN, extensions, fingerprint |
| A live server's currently-presented cert | SSL Certificate Checker | Everything above, plus chain and trust validation against the live connection |
The distinction that trips people up most: a CSR and the certificate eventually issued from it often share the same subject and public key, but only the certificate carries an issuer, validity dates, and a CA signature — fields that simply don't exist yet at the request stage.
Decoding a Certificate the Manual Way
The command-line equivalent of everything this page shows is openssl x509 -in yourfile.crt -noout -text, which has been the standard way to inspect a certificate for decades and remains the most authoritative option when you need output to pipe into other tooling or a script. This decoder exists for the more common everyday case: a quick check without opening a terminal, particularly useful when reviewing a certificate someone sent you mid-conversation or on a machine without OpenSSL installed.
What This Tool Doesn't Do
This decoder reads and displays a certificate's own structure — it doesn't verify the embedded signature against the issuer's public key, doesn't build or validate a chain of trust up to a root CA, and doesn't check revocation status through OCSP or a CRL. All of those require either the issuer's certificate (to check the signature) or a live network call (to check revocation), neither of which this offline, paste-based tool performs. For a full live check against an actual server — chain validation, trust, and current revocation status included — use the SSL Certificate Checker instead.
When You'd Actually Paste a Certificate In Here
Related Reading
For decoding an unsigned request before it's submitted to a CA, see the CSR Decoder. For generating a new CSR from scratch, use the CSR Generator. For a live trust and chain check against a real server, see the SSL Certificate Checker. For background on validation levels and the trust chain these fields feed into, read SSL Certificate Validation Levels: EV vs OV vs DV and Certificate Security & Trust Verification.