X.509 Certificate Decoder
Paste one or more PEM-encoded certificates to inspect subject, issuer, validity, SANs, and fingerprints. Parsed entirely in your browser — no upload, no verification of the signature.
The example is a locally generated, self-signed placeholder for example.com — not a certificate issued for any real domain. Paste your own certificate to inspect real data.
Paste a certificate to see its fields.
About this tool
X.509 Certificate Decoder
This tool parses the ASN.1 DER structure inside a PEM certificate directly in JavaScript — base64-decoding the PEM block, walking the TLV-encoded Certificate structure, and pulling out the fields you'd normally need openssl x509 -text for: subject and issuer distinguished names, validity dates, serial number, signature algorithm, public key algorithm and size, and standard extensions (Subject Alternative Name, Basic Constraints, Key Usage, Extended Key Usage, Subject/Authority Key Identifier).
SHA-256 and SHA-1 fingerprints are computed over the raw certificate bytes using the browser's Web Crypto API — the same fingerprints you'd see in a browser's certificate viewer.
This is a decoder, not a validator: it does not check the signature, does not build or verify a chain of trust, and does not consult any revocation list (CRL/OCSP). Expiry and self-signed status are flagged, but a certificate parsing cleanly is not the same as it being trustworthy.
Compared to the decoder utilities on certificate authorities' sites and SSL shopper tools, the difference is what happens to the bytes you paste. Most web decoders ship your certificate — often with internal hostnames, your organization's details, and sometimes public keys of internal services — to a server for parsing. This one never does: the ASN.1 walk happens in JavaScript in your tab, which makes it usable as an offline certificate reader for certs you can't paste anywhere else — internal CA issuers, staging endpoints, VPN and mTLS certs, or a chain from a client you're debugging. The tradeoff is honest: a server-side decoder can validate chains; this one deliberately doesn't, it just shows you exactly what's encoded.
When to use it
Check what's actually in a cert file
Paste a .pem or .crt file's contents to see its SANs, expiry, and key algorithm without running openssl.
Debug a hostname mismatch
Compare the SAN list against the hostname you're connecting to — a cert only covers the exact names listed there.
Check a chain's fingerprints against a known-good value
Paste a full chain (multiple PEM blocks) to decode each certificate and compare its SHA-256 fingerprint to a pinned value.
Questions
Does this verify the certificate is trusted or authentic?
No. It only decodes and displays the fields encoded in the certificate. It does not check the signature, build a trust chain, or check revocation status.
How do I read a .pem file?
To read a .pem file, open it in any text editor — it's plain text, not binary — and you'll see one or more blocks starting with -----BEGIN CERTIFICATE----- and ending with -----END CERT-----. Paste the whole block — header and footer included — into the decoder above, and every field renders: subject, issuer, validity, SANs, key usage, fingerprints. On the command line the equivalent is openssl x509 -in cert.pem -text -noout. If the file holds a chain or a bundle, each certificate block is decoded separately.
What is the difference between .pem, .crt, .cer, and .der?
They're containers, not different formats. PEM is Base64 text wrapped in BEGIN/END lines; DER is the same certificate as raw binary. .crt and .cer usually contain a PEM certificate (sometimes DER); .key holds a private key — don't paste that anywhere. This tool accepts any PEM-encoded certificate regardless of file extension, and binary DER is not supported.
Can I paste a full certificate chain?
Yes — paste multiple -----BEGIN CERTIFICATE----- blocks and each one is decoded separately, with tabs to switch between them.
Is my certificate uploaded anywhere?
No. Parsing and fingerprinting happen entirely in your browser using the Web Crypto API — nothing is sent to a server.
What is the x5c header field?
x5c ("X.509 certificate chain", RFC 7515 §4.1.6) is a JWT header parameter that carries the signing certificate chain as an array of Base64-encoded DER certificates, leaf first. Copy the Base64 value out of the decoded header, wrap it in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines, and paste it here — the decoder reads it like any PEM certificate. What comes back is what the token alone doesn't tell you: the subject, issuer, and validity window of the certificate behind the signature. x5t and x5t#S256 are related header fields — thumbprints of that same certificate, which you can match against the SHA-1 and SHA-256 fingerprints this tool computes.
Can this decode a public key or a JWK?
No — this tool decodes certificates, and that distinction is the point. A PEM public key block (BEGIN PUBLIC KEY) or a JWK (JSON Web Key, the JSON format served at JWKS endpoints) is a bare key with no subject, issuer, or expiry to show, and x509 parsing rejects it. What a certificate adds over a key is identity and validity, and that's what this tool displays. If you have a JWK that embeds an x5c array, decode the embedded value here; the JWK's n/e or x/y fields themselves are not certificates.
Why does it say 'couldn't parse' for some extensions?
Only the most common extensions have dedicated decoders. Less common ones still show their OID and critical flag, just not a human-readable summary of their contents.
Why does a certificate show as valid but the browser warns me?
Decoding shows what the certificate says; browsers additionally check who issued it, whether the chain roots in a trust store, whether the name matches the site, and whether it was revoked. A cert can be internally well-formed and still untrusted — that's a chain problem, which is exactly what this decoder leaves to other tools.
Related resources
JWT key material
x5c, JWK, and how this decoder fits in
An x5c ("X.509 certificate chain") header parameter is where a signed JWT carries its signing certificate. Defined in RFC 7515 §4.1.6, it is an array of Base64-encoded DER certificates — leaf first, intermediate CAs after. A verifier downloads the issuer's keys or fetches them from a JWKS endpoint; a token with an x5c header hands you the certificates directly, which is why you see it in SAML-to-OIDC bridges, Apple/Google sign-in token responses, and enterprise SSO setups.
A JWK (JSON Web Key) is the machine-readable key format that lives in a JWKS endpoint. JWKs describe keys — an RSA JWK carries the modulus and exponent as JSON fields, an EC JWK the curve and coordinates — while x5c carries certificates. They overlap in one place: a JWK may embed an x5c array alongside n/e or x/y, and that embedded value is the same Base64 DER a JWT header carries.
This tool is the paste-and-decode half of that pipeline. The Base64 value inside x5c is just a DER certificate without its PEM wrapper — so to read it here, re-wrap it: -----BEGIN CERTIFICATE-----, the Base64 from the header, -----END CERTIFICATE-----, and paste. You get back the subject, issuer, validity window, and fingerprints — the fields you need to check a token's signing certificate before trusting it. Related fields: x5t is the certificate's SHA-1 thumbprint (match it against this tool's SHA-1 fingerprint), and x5t#S256 is the SHA-256 variant (this tool computes both).
Scope, stated plainly: this decoder accepts PEM certificates only. A PEM public key block (BEGIN PUBLIC KEY) or a JWK's JSON is not a certificate and is not parsed — a key on its own has no subject, issuer, or expiry to decode, which is exactly the information a certificate adds. For the token side, paste the JWT itself into the JWT decoder, copy the x5c value from the decoded header, and bring it here.