X.509 Certificate Decoder
Decode PEM X.509 certificates in your browser — subject, issuer, validity, public key, SANs and extensions. A compact DER/ASN.1 parser, nothing uploaded.
PEM certificate
How it works
- Paste a PEM certificate (the
-----BEGIN CERTIFICATE-----block from a.crt,.pem, or TLS handshake). - The tool base64-decodes the body into DER and walks the ASN.1 structure: version, serial, signature, issuer, validity, subject, public key, and extensions.
- Subject Alternative Names (DNS / IP / email / URI) and key usage flags are decoded from the standard X.509 extension OIDs.
- Everything is parsed on your device — certificates are public by design, but your data still never leaves the browser.
About X.509 Certificate Decoder
X.509 certificates are the public keys of TLS and PKI. A certificate is an ASN.1 DER structure base64-encoded into PEM: who issued it (issuer), who it belongs to (subject), the validity window, the public key and algorithm, and extensions such as Subject Alternative Names (the hostnames the certificate is valid for) and key usage. Reading these fields by hand means decoding DER byte by byte — this tool does that for you so you can quickly answer questions like “when does this cert expire?”, “which domains is it valid for?”, or “is it CA-signed?”.
This decoder is for inspection only — it does not verify the trust chain or the signature (that requires the issuer’s public key and a CA store). For trust validation use a proper TLS stack. Note that certificates are public information; still, this tool runs locally so you can inspect internal-PKI certs, customer certs, or key-material-adjacent data without third-party servers seeing them.
What DER actually is
A certificate is a binary ASN.1 structure — a SEQUENCE of tagged, length-prefixed values — and DER is the canonical encoding of it: definite lengths only, minimal length octets, none of the indefinite-length forms BER permits. PEM is simply that DER base64-encoded between BEGIN and END lines, which is why this tool strips the armour with a header regex and hands the raw bytes to the parser.
The reader itself is short: read the tag byte, read the length (short form, or long form with one to four length octets, with zero rejected as indefinite), then check that the value does not run past the buffer and raise `Truncated DER` or `DER length overruns buffer` if it does. Every read carries explicit start and end bounds rather than slicing, so offsets stay absolute within the whole buffer and a nested structure can be handed to a fresh reader without copying.
Walking the structure
Decoding descends Certificate → tbsCertificate → optional `[0]` version, where an absent tag means v1 and the tool reports the parsed value plus one, then serial, signature algorithm, issuer, validity, subject, SubjectPublicKeyInfo, and finally any `[3]` extensions. Names nest twice over — SEQUENCE of SET of SEQUENCE of an OID and a value — and values are decoded by tag, including BMPString read as UTF-16BE rather than as bytes.
The SPKI is opened one level deeper: for RSA the tool skips the BIT STRING's unused-bits octet and reports the modulus length and exponent, for EC it reads the named-curve OID from the algorithm parameters. Extensions get real renderers rather than hex dumps — subjectAltName split by general-name tag (`0x82` DNS, `0x81` email, `0x86` URI, `0x87` raw IP bytes), keyUsage unpacked from its bit string into the nine named usages, basicConstraints as CA plus pathLen, and extendedKeyUsage resolved to serverAuth, clientAuth, codeSigning and the rest.
What this parser does not tell you
It verifies no signature, builds no chain to a trust anchor, matches no hostname, and makes no network calls at all — so it cannot tell you whether a certificate has been revoked, because CRL distribution points and OCSP responders would both require fetching. The validity dates shown mean the window is well-formed and in the future, not that anyone vouches for the certificate. Trust decisions belong to a real TLS stack with a populated root store.
Two parsing limits are worth knowing. Only the first certificate in a pasted chain is decoded, because the surrounding bytes are ignored after the outermost SEQUENCE, so a full chain is silently truncated to its first entry rather than reported as an error. And the PEM stripper only matches uppercase-letter header text, so blocks whose label contains digits or whose body carries parameters such as `Proc-Type:` will confuse it.
Frequently Asked Questions
How do I decode an X.509 certificate?
Can I decode CSR (Certificate Signing Request)?
Is my data sent to a server?
Do I need an account or API key?
Can I use these tools offline?
All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.