Decode PEM or DER certificates, chains and CSRs: subject, SANs, expiry, key type, extensions, fingerprints and chain order with signature checks. Private keys are refused.
Loading Certificate Decoder…
Loading Certificate Decoder…
When a TLS handshake fails, the answer is almost always in the certificate: an expired date, a host name missing from the Subject Alternative Names, an intermediate left out of the chain, or a chain in the wrong order. This decoder reads PEM text (a single certificate, a whole chain, a CSR or a public key), Base64 or hex DER, and .crt, .cer, .der and .p7b files, and shows what matters in plain words: who it's for, who issued it, when it expires relative to your clock, every SAN, the key type and size, the signature algorithm, key usage, extended key usage, basic constraints, CRL and OCSP URLs, and SHA-256 and SHA-1 fingerprints plus an SPKI pin. For a chain, it orders the certificates leaf to root and verifies each signature with the issuer's public key. It flags the classic mistakes — no SANs on a server certificate, SHA-1 signatures, RSA keys under 2048 bits, validity periods too long for public TLS. Its output is tested field by field against OpenSSL for RSA, ECDSA P-256 and P-384, Ed25519 and RSA-PSS certificates, a CSR and a three-certificate chain. Private keys are refused before anything is parsed.
PEM blocks are found by their BEGIN/END markers (Windows line endings, extra whitespace and RFC 1421 headers are tolerated), Base64-decoded, and read with a strict DER parser that reports truncated or malformed data with a byte offset. Names are shown in RFC 2253 order like openssl -nameopt RFC2253, with UTF-8, PrintableString, BMPString and Teletex strings decoded.
Each certificate's issuer is matched to another certificate's subject, confirmed by the Authority and Subject Key Identifiers when present. The leaf is the certificate that issued nothing; the chain is followed to a self-signed root or to the last certificate present. Signatures are verified with Web Crypto: RSA PKCS#1 v1.5, RSA-PSS, ECDSA on P-256/384/521, and Ed25519 where the browser supports it.
Before decoding, the input is checked for private key PEM headers, PuTTY keys and the DER structures of PKCS#8, PKCS#1, SEC 1 and encrypted private keys. If one is found the input is cleared immediately, so the key never reaches the page state, the share system or storage.
Fingerprints are the SHA-256 and SHA-1 hashes of the certificate's DER bytes, matching openssl x509 -fingerprint and what browsers show. The SPKI pin is the Base64 SHA-256 of the public key info, the format used for certificate pinning in Android network security config and HPKP-style pins; it stays the same when a certificate is renewed with the same key.
Short answers for the things developers usually ask before trusting a tool.
No. The certificate is decoded in your browser with a built-in DER parser, and fingerprints and signature checks use the Web Crypto API. Nothing is sent to a server. Certificates are public anyway — they're sent to every visitor of your site — but CSRs and internal certificates may not be.
The tool detects private keys (PRIVATE KEY, RSA/EC PRIVATE KEY, encrypted and OpenSSH keys, and DER-encoded keys) before decoding anything, removes the text from the page and shows a warning. It is never parsed, stored or shared. A private key should never be pasted into any website, including this one; if it was pasted somewhere else, replace it.
Paste the whole chain (for example your fullchain.pem or the bundle from your CA). The tool works out which certificate issued which, shows them leaf → intermediate → root, checks each signature against the next certificate's public key, and tells you if the order was wrong or an intermediate is missing. "Download ordered chain" saves them in the order a server should send them.
Browsers ignore the Common Name and only check the Subject Alternative Name (SAN) list, and have for years. If your host name isn't in the SAN list, the certificate isn't valid for it. The tool warns when a server certificate has no DNS or IP SANs.
No, deliberately. Fetching a site's certificate, or checking OCSP and CRLs, needs network requests from a server, which this tool deliberately doesn't make: your input is only processed in the page. To grab a site's chain, run: openssl s_client -connect example.com:443 -showcerts, then paste the output here.
PKCS#12 files bundle the private key with the certificates and are password-protected, so they're not opened here. Extract just the certificates with openssl pkcs12 -in file.pfx -nokeys -out certs.pem and paste those. PKCS#7 (.p7b) bundles, which contain only certificates, are supported.
Useful follow-ups when one conversion usually turns into three more.
Decode JWT header and payload locally so you can inspect claims and expiry quickly.
Convert text to Base64 and back with Unicode-safe browser-side processing.
Generate MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hashes from text.