Read an SSL certificate, CSR or public key: names, dates, key size and fingerprints
Runs in your browser. Nothing you type is sent anywhere. Updated on 25 Oct 2026.A certificate decoder turns the Base64 of a PEM file into the fields a browser reads: subject, issuer, the 2 validity dates, serial, signature algorithm, key size, subject alternative names and the SHA-1 and SHA-256 fingerprints. Certificates, CSRs and public keys are all read here in your browser.
Paste a PEM block into the box, or press Choose a file for a .crt, .cer, .pem, .der or .csr file.
Read the card for each block: subject, issuer, validity dates, key and the names it covers.
Press Copy beside the serial or a fingerprint to take that value alone.
Press Copy everything, or Ctrl+Enter, for the whole summary as text.
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 ASN.1 and DER parsing is written out in this repository rather than pulled from a library, so the code that reads your certificate can be read back. That also keeps the page small: no 300 KB crypto library is downloaded to walk a structure defined in two pages of ASN.1.
Warnings appear where they matter: an expired certificate, one under thirty days from expiry, SHA-1 or MD5 signatures, RSA keys below 2048 bits, a missing subjectAltName, a lifetime over the 398 days browsers allow, and what a wildcard name does and does not cover.
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.
Paste the certificate and the validity line answers it: expired, valid, or valid with the number of days left, worked out against the clock on your own machine. Under thirty days raises a warning, because a certificate that lapses on a Saturday takes the site down until somebody notices.
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.
Both take the same hash of the same bytes: SHA-256 over the whole DER-encoded certificate, which is also what openssl x509 -fingerprint -sha256 prints. Comparing the three is the standard way to confirm that the certificate on your server is the one being served.
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.
Chrome stopped reading the Common Name in version 58, released in 2017, and every other browser followed. A certificate without a subjectAltName extension listing each hostname is rejected however correct its CN is, so the warning is the actual reason a site shows an error.
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.
Also works as: Certificate Expiry Checker.
In the collection Security Tools for Developers.