Work out what is inside a PEM file, whichever of the five things it turns out to be
Runs in your browser. Nothing you type is sent anywhere. Updated on 25 Oct 2026.A PEM decoder works out what each block holds: a certificate, a chain, a signing request, a public key or a private key. Pasted together, the built-in examples read as Self-signed certificate for test.omnikit.invalid; Self-signed certificate for Omnikit Internal Root CA; Signing request for shop.omnikit.invalid. Each block is read in turn; a private key is left undecoded.
Open the page with a chain of two certificates already decoded.
Paste your PEM file; each BEGIN block gets its own numbered card.
Read the heading of each card to see whether it holds a certificate, a signing request or a public key.
Press Copy everything for a text summary of every block.
Paste a PEM block, or drop a .crt, .cer, .pem, .der or .csr file, and every field is listed: subject and issuer as full distinguished names, the serial in hex and in decimal, both validity dates with whether the certificate is in date at this moment, the signature algorithm, the public key algorithm and its size, every subject alternative name, the extensions with their critical flag, and the SHA-1 and SHA-256 fingerprints. The SHA-256 of the public key is given as well, in the sha256// form a pinning header wants.
Three shapes are read, and which one you have is worked out from the label on the BEGIN line rather than guessed. A certificate is read as RFC 5280 defines it. A PKCS#10 signing request is read including the names hidden inside its extensionRequest attribute, which is where a CSR keeps its SANs and where most decoders stop looking. A SubjectPublicKeyInfo is read on its own, so a key and the request it belongs to can be compared by fingerprint. Paste a whole chain and each certificate is read in order, with a note when the order is wrong.
A private key is recognised and deliberately not decoded. Nothing leaves your device either way, but a page that happily prints the components of a private key trains a habit that will one day be practised on a site that does upload it.
The rest of the article, and all 7 questions about Certificate Decoder, are on the Certificate Decoder page.
No. The decoding happens in the page, in JavaScript, with no network request of any kind. Certificates are public by design, but chains and internal CA files get pasted by mistake, so the parsing is done locally and there is nothing on a server to delete afterwards.
A certificate signing request states what you are asking for: a subject name, the hostnames you want covered, and your public key. A certificate is what the authority signs and returns, with dates, a serial number and the issuer's own name attached. Both are decoded here.
Recognising one is supported; decoding it is refused on purpose. Nothing is sent anywhere, but a private key does not belong in a browser tab at all. If a key has been pasted into any website, generate a new one, reissue the certificate and revoke the old one.
Server se certificate ka PEM copy karein, paste karein, and every field appears at once: subject, issuer, expiry date, key size and fingerprints. Yeh check karein whether the expiry date has passed and whether every hostname you serve is listed under subject alternative names.
Still stuck? Ask about Certificate Decoder and anybody who knows can answer. No account needed.
Same job, other tools: JWT Decoder – Paste a token to read its header, payload and expiry.
On the related tools: Passphrase Generator – Three to ten random words you can actually remember · Bcrypt Generator – Generate a bcrypt hash for a test user or a config file.
In the collection Security Tools for Developers.