Certificate Decoder

Common questions

How do I decode a PEM certificate?

Paste it into the box, including the BEGIN CERTIFICATE and END CERTIFICATE lines, and the fields appear beside it as you type. You can also press Open file and pick a .pem, .crt, .cer or .der file, or drag the file onto the dark panel. A text file is read as it is; a binary DER file is turned back into base64 and shown in the box, so what the page decoded is always visible to you. A certificate copied out of a log line or a JSON field with no BEGIN and END lines around it still works: the text is read as base64 DER, and the page says that is what it did. One reading takes up to 200,000 characters, which is a chain many times over.

Does a certificate that decodes here mean it is valid?

No, and that is the most important thing on this page. Decoding reads the fields; checking is four separate jobs that this page does not do. It does not verify the signature, it does not build or check a chain up to a root your machine trusts, it does not ask an OCSP responder or read a CRL to see whether the certificate was revoked, and it does not compare a hostname against the names inside. Two of those would need something a page like this does not have: a revocation check needs the network, and a chain needs the store of root certificates your system keeps. The other two, the signature and the hostname, are not done here either, because a tick that covered part of the question would be more misleading than no tick at all. So an expired certificate, a self-signed one and a certificate issued for somebody else's domain all decode here exactly as cleanly as the one your server is really using, and the fields, the dates and the notes are how you tell them apart.

What is the SHA-256 fingerprint, and is it the same one my browser shows?

It is the SHA-256 digest of the certificate's own DER bytes, which is the same value openssl prints for -fingerprint -sha256 and the same one a browser shows in its certificate viewer. That is what makes it useful: it identifies this exact certificate, so you can tell whether the file on your laptop is the one the server is actually sending, or whether two copies of a certificate are the same. You can switch between the colon separated form and the plain hex form, and copy either. The digest is computed in this tab from the bytes you pasted, and the tests compare it against the SHA-256 in Node's standard library on every run.

What happens if I paste a private key with the certificate?

Nothing is decoded and nothing is kept. A .pem bundle often holds the key and the certificate together, and people paste the whole file by habit, so any BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY, BEGIN ENCRYPTED PRIVATE KEY or BEGIN OPENSSH PRIVATE KEY block is refused by its label before any body is read. The message names the block it found and never echoes the key material back, and the check runs a second time before anything is written to this browser, so key material cannot reach storage even by accident. Paste only the part between BEGIN CERTIFICATE and END CERTIFICATE.

Can it read a whole chain, or a certificate signing request?

A chain, yes: paste every block and each certificate is decoded in the order it appears, with a numbered control for moving between them and a separate fingerprint for each. Nothing here checks that they chain together, and the page says so. A certificate signing request is a different thing, and it is refused with that in the message: a CSR is what you send to a certificate authority, and the certificate is what comes back. A public key block, a CRL and a PKCS#7 bundle are each named the same way rather than being read as a certificate.

Why does my certificate say there is no SAN?

Because it has no subject alternative name extension, and that is worth knowing. Browsers have matched a hostname against the SAN and ignored the common name since 2017, so a certificate with a hostname only in its CN will not match that hostname in a browser, however correct the rest of it looks. The page lists every name it does carry with its type, DNS, IP, email or URI, and counts them in the SANs cell. Other notes appear the same way when they apply: a self-signed certificate, an RSA key below 2,048 bits, a SHA-1 signature, or a lifetime longer than the 398 days public authorities have issued for TLS since September 2020.

How is expiry worked out?

From the two dates in the certificate, read exactly as written and shown in full. A UTCTime carries a two digit year and follows the RFC 5280 rule, where 00 to 49 means 2000 to 2049 and 50 to 99 means 1950 to 1999; a date past 2049 is written as a GeneralizedTime with its year in full, and both are handled. The window is inclusive: the certificate is in date up to the last millisecond of its not-after time, and expired one millisecond later, and the page counts whole days either way. A date that is not a date, a month 13 or a minute 61, is refused with the characters it read rather than being turned into a number.

Is my certificate uploaded, or remembered?

Nothing is uploaded and nothing is sent anywhere: the parsing, the decoding and the fingerprint all happen in this tab. A certificate is public by design, so what you paste is kept in this browser alone and is still here when you come back, and the Start over button above the tool forgets it. Two things are never kept: anything holding a private key, and a paste longer than 40,000 characters, which is read and decoded in full but not written to storage. If your browser blocks storage entirely, everything on the page still works and nothing is remembered between visits.