Is the certificate I paste sent anywhere?

No. The page decodes it and checks the signatures in your browser and sends nothing; the text is not stored either. Certificates are public anyway, but a CSR can reveal names you have not published yet, and a private key pasted by mistake is rejected without being read further. This page loads no ads or other third-party scripts.

How do I check when a certificate expires?

Paste it and read “Valid until” and “Status”; the tool warns within 30 days of expiry. To check what a server actually sends, save its chain first, for example with openssl s_client -connect example.com:443 -showcerts, and paste the certificates.

How do I decode a CSR?

Paste the block that starts with -----BEGIN CERTIFICATE REQUEST-----. The tool shows the subject, the requested names and extensions and the key, and checks that the request is signed with its own key. The OpenSSL equivalent is openssl req -in request.csr -noout -text -verify.

What is the difference between PEM, DER, CRT and CER?

DER is the binary encoding; PEM is the same bytes in Base64 between BEGIN and END lines. The extensions .crt and .cer are used for both, so the name does not tell you which one a file contains. The tool accepts either.

Can it tell me whether a certificate matches my private key?

Not by pasting the key, and you should not paste a private key into any web page. Instead compute the key’s public key pin locally with the OpenSSL command above and compare it with the pin shown for the certificate. Equal pins mean the same key.

Certificate Decoder

Paste a certificate, a full chain or a CSR to read every field and check expiry, names and chain order.

Runs in your browser. Your input is not sent anywhere.

How to use it

Paste one or more PEM blocks, such as the contents of fullchain.pem, or choose a .pem, .crt, .cer, .der, .csr or .p7b file.
Read the chain check first: it says whether each certificate is issued by the next one and whether the signatures verify.
Then read each certificate: the warnings at the top, the names, the validity dates and the key.
Copy the result as text if you want to keep it or send it to a colleague.

The decoder reads certificates and certificate signing requests (CSRs) only. If you paste a private key by mistake, it stops without reading it.

Worked example: ISRG Root X1

ISRG Root X1 is the RSA root certificate of Let’s Encrypt, published on its certificates page. Decoded, it shows these values:

Decoded fields of ISRG Root X1

Subject              C=US, O=Internet Security Research Group, CN=ISRG Root X1
Issuer               C=US, O=Internet Security Research Group, CN=ISRG Root X1
Valid from           2015-06-04 11:04:38 UTC
Valid until          2035-06-04 11:04:38 UTC
Validity period      7,306 days
Public key           RSA 4096 bits, exponent 65537
Signature algorithm  sha256WithRSAEncryption
Key usage            keyCertSign, cRLSign
Basic constraints    CA: yes
SHA-256 fingerprint  96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:
                     CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6

Subject and issuer are the same, so this is a self-signed root, and the chain check reports that its own signature verifies. The fingerprint matches the one Let’s Encrypt publishes, which is how you confirm that a root in a trust store is the genuine one. The period is 7,306 days rather than 7,305 because the validity includes both the first and the last second, and any part of a day counts as a day, the way the CA/Browser Forum counts it.

How the tool reads a certificate

A PEM file is Base64 text between BEGIN and END lines (RFC 7468). Inside is DER, a binary encoding of ASN.1. The tool decodes the Base64, reads the DER structure field by field as RFC 5280 defines it for certificates and RFC 2986 for CSRs, and rejects anything that is not strict DER. PKCS #7 files (.p7b) are opened and the certificates inside are read in the order they are stored. PKCS #7 does not define an order, so the chain check may report one that differs and suggest another.

Fingerprints are the SHA-256 and SHA-1 hashes of the DER bytes, calculated with Web Crypto. They identify the certificate; they have nothing to do with the hash in the signature algorithm. The public key pin is the Base64 SHA-256 hash of the public key structure (SubjectPublicKeyInfo), the form RFC 7469 and Android’s network security configuration use. A certificate and a CSR with the same pin contain the same key.

The chain check assumes the order a TLS server sends: the server’s own certificate first, then each certificate that issued the previous one (RFC 8446, section 4.4.2). For each pair it compares the issuer name with the subject of the next certificate, the authority and subject key identifiers, and verifies the signature with the next certificate’s public key using Web Crypto. RSA (PKCS #1 v1.5 and PSS), ECDSA on P-256, P-384 and P-521, and Ed25519 are verified where the browser supports them; other algorithms are reported as not checked.

The tool does not contact anyone: it does not download missing intermediates, does not check revocation (OCSP or CRL) and does not know which roots your systems trust. A result of “signature verified” means the bytes fit together, not that a browser will trust the chain.

Warnings and the rules behind them

What the warnings check
Warning	Rule
Expires within 30 days	A convention of this tool, not a standard.
No subject alternative names	Browsers match host names only against the SAN extension; the common name is ignored (RFC 9525).
Signature uses SHA-1 or MD5	Browsers stopped accepting SHA-1 signatures on certificates in 2017. Not raised for the self-signature of a root, which clients do not check.
RSA key below 2048 bits	The CA/Browser Forum Baseline Requirements (section 6.1.5) require at least 2048 bits.
Validity longer than allowed	Baseline Requirements section 6.3.2: 398 days from 2020-09-01, 200 days from 2026-03-15, 100 days from 2027-03-15 and 47 days from 2029-03-15, applied to the start date of non-CA certificates that are not self-signed. Private CAs are not bound by it.
Unknown critical extension	RFC 5280 section 4.2: software must reject a certificate with a critical extension it does not recognize.

The same checks with OpenSSL

OpenSSL commands

# All fields of a certificate, and only its dates
openssl x509 -in cert.pem -noout -text
openssl x509 -in cert.pem -noout -dates

# A CSR, including the check of its signature
openssl req -in request.csr -noout -text -verify

# SHA-256 fingerprint
openssl x509 -in cert.pem -noout -fingerprint -sha256

# Chain: leaf.pem against the intermediates and a root
openssl verify -CAfile root.pem -untrusted intermediates.pem leaf.pem

# Certificates of a PKCS #7 file
openssl pkcs7 -in chain.p7b -print_certs -noout

To compare a private key with a certificate without pasting the key anywhere, compute its public key pin locally and compare it with the pin the tool shows:

Public key pin of a private key

openssl pkey -in key.pem -pubout -outform DER | openssl dgst -sha256 -binary | openssl base64

Common mistakes

Serving only the server certificate without its intermediate. Some browsers fill in a missing intermediate themselves, by downloading it or from a preloaded list, so the site seems to work, while many command-line tools and apps fail.
Putting the certificates of a chain file in the wrong order, for example the intermediate before the server certificate.
Relying on the common name. A certificate without the host name in its subject alternative names fails in current browsers.
Installing a renewed certificate but reloading the wrong service, so the old one is still served. Compare the fingerprint or the expiry date of what the server sends.
Mixing up the fingerprint hash and the signature hash. A SHA-1 fingerprint says nothing about the strength of the certificate.

Sources

Frequently asked questions

Is the certificate I paste sent anywhere?: No. The page decodes it and checks the signatures in your browser and sends nothing; the text is not stored either. Certificates are public anyway, but a CSR can reveal names you have not published yet, and a private key pasted by mistake is rejected without being read further. This page loads no ads or other third-party scripts.
How do I check when a certificate expires?: Paste it and read “Valid until” and “Status”; the tool warns within 30 days of expiry. To check what a server actually sends, save its chain first, for example with openssl s_client -connect example.com:443 -showcerts, and paste the certificates.
How do I decode a CSR?: Paste the block that starts with -----BEGIN CERTIFICATE REQUEST-----. The tool shows the subject, the requested names and extensions and the key, and checks that the request is signed with its own key. The OpenSSL equivalent is openssl req -in request.csr -noout -text -verify.
What is the difference between PEM, DER, CRT and CER?: DER is the binary encoding; PEM is the same bytes in Base64 between BEGIN and END lines. The extensions .crt and .cer are used for both, so the name does not tell you which one a file contains. The tool accepts either.
Can it tell me whether a certificate matches my private key?: Not by pasting the key, and you should not paste a private key into any web page. Instead compute the key’s public key pin locally with the OpenSSL command above and compare it with the pin shown for the certificate. Equal pins mean the same key.

Last updated: October 4, 2026