Skip to main content
HostTracker
HostTracker
website monitoring service
Status pages Instant check Price
Login Register

Certificate decoder: read a PEM certificate or CSR in your browser

Paste a PEM-encoded X.509 certificate or a certificate signing request and see its subject, issuer, validity, public key, extensions and fingerprints. Decoding runs entirely in your browser - the text never leaves the page, no sign-up needed.

What the certificate decoder reads

The subject and issuer, the validity dates, the public key type and size, every subject alternative name, the key usage and extended key usage flags, and the SHA-256 and SHA-1 fingerprints - straight out of the certificate's own DER structure.

Find out more

Why paste, not upload

A certificate is public by design - your server already hands it to every visitor's browser during the TLS handshake. This tool still never sends what you paste anywhere: decoding runs locally, in JavaScript, with no request leaving the page.

Find out more

A decode tells you today. Monitoring tells you the day it changes

This is a one-time read of the text you pasted. An SSL certificate monitor fetches the certificate your server actually serves on a schedule and warns you 30, 7 and 1 day before it expires.

Find out more

This decodes the certificate or CSR text you paste. To check the certificate a server actually presents on a real connection, from 300+ locations, use the SSL certificate checker. For expiry alerts before a live certificate lapses, see SSL certificate monitoring.

Key takeaways

  • This tool decodes a pasted PEM certificate or CSR entirely in your browser, using a built-in DER parser; the text is never uploaded or sent to a server.
  • For a certificate it shows the subject, issuer, validity dates, serial number, signature algorithm, public key type and size, subject alternative names, key usage and extended key usage, and SHA-256 and SHA-1 fingerprints.
  • It also reads certificate signing requests (CSRs), showing the requested subject, public key and subject alternative names, and it decodes multiple concatenated PEM blocks as a chain, in order.
  • It is free, needs no login and no credit card.
  • For the certificate a server is actually presenting, see the SSL certificate checker, and for expiry alerts before a live certificate lapses, see SSL certificate monitoring.

Frequently asked questions.

PEM is the text form of a certificate or key (RFC 7468): base64 between a "-----BEGIN" line and a matching "-----END" line. Files ending in .pem, .crt and .csr are usually PEM, while .cer and .der files are often binary. This decoder reads blocks labeled CERTIFICATE, X509 CERTIFICATE, CERTIFICATE REQUEST and NEW CERTIFICATE REQUEST, and it also accepts bare base64 with the header lines removed. Only text is read, so a binary file has to be converted first.
Yes. A certificate is public data - it is exactly what your server already sends to every visitor's browser. Nothing you paste is uploaded or stored; decoding happens locally in your browser. A CSR is also fine to paste, since it carries no private key material. Never paste a PRIVATE KEY block anywhere, including here - the tool detects one and refuses to read it.
Paste the PEM block that begins with BEGIN CERTIFICATE REQUEST. A certificate signing request (CSR) is what you send to a certificate authority when requesting a certificate; it carries the subject, the public key and, usually, the domain names requested. The tool shows the subject, the public key type and size, the signature algorithm, and the requested subject alternative names read from the extensionRequest attribute. To also verify the CSR signature, run openssl req -in request.csr -noout -text -verify.
OpenSSL on your own machine gives the same information, plus the checks this page leaves out. Run openssl x509 -in cert.pem -noout -text to decode a certificate, or openssl x509 -in cert.pem -noout -fingerprint -sha256 for its SHA-256 fingerprint, printed with colons. To read the expiry date of the certificate a server is using right now, rather than of a file, the guide to checking SSL certificate expiry shows the openssl s_client command that fetches it.
The decoder reads text only, so convert a binary file first. For a binary .cer or .der file run openssl x509 -inform der -in cert.cer -out cert.pem. For a .p7b bundle run openssl pkcs7 -in bundle.p7b -print_certs -out chain.pem, and add -inform der to that command when the .p7b file is binary. A PKCS#12 (.pfx) archive also has to be converted to PEM before you paste it.
Yes. Paste several PEM blocks one after another - a leaf certificate followed by its intermediates, for example - and each one is decoded on its own and shown in the order it appears. That order is worth checking: the server certificate comes first and each issuer after the certificate it signed (RFC 8446 section 4.4.2). A first block showing CA:TRUE, or an Authority Key Identifier that does not match the next certificate's Subject Key Identifier, means the bundle was assembled in the wrong order or mixes two chains.
These show up directly in the decoded fields:
  • A missing hostname: the name is not among the subject alternative names. Make a new CSR with every name.
  • Expiry: a red "Expired N days ago" or amber "Expires in N days". Renew, then check the live server.
  • A self-signed certificate: issuer and subject are identical.
  • A weak key or old signature: an RSA key under 2048 bits, or sha1WithRSAEncryption. Use RSA 2048-bit or larger, or EC P-256.
  • The wrong certificate: CA:TRUE, or no TLS server authentication in Extended Key Usage. Install the one whose names list your hostname.
Certificates can carry extensions beyond the common set this tool decodes in full - Certificate Transparency SCTs and certificate policy statements are two examples. An extension the tool does not decode is still listed, by its object identifier, rather than hidden. Subject attributes work the same way: it names CN, O, OU, C, ST, L and emailAddress and shows any other by its identifier. 2.5.4.5 is serialNumber and 2.5.4.15 is businessCategory, which extended validation certificates carry.
They are hashes of the certificate's raw DER bytes - a short, unique way to confirm that two copies of "the same" certificate are actually identical, or to compare against a fingerprint published or pinned elsewhere. The decoder computes them in your browser with the Web Crypto API.
Not here: the decoder never reads a private key, and a key should never go into a web page. Compare the two on your own machine instead. Run openssl x509 -in cert.pem -noout -pubkey | openssl sha256 and openssl pkey -in private.key -pubout | openssl sha256. They print a hash of the public key from each file, and matching hashes mean the pair belongs together.
Decoding shows what a certificate says about itself and proves none of it. Signatures are not verified, neither a certificate's against its issuer nor a CSR's against its own key. Trust is not evaluated: there is no chain building to a root store and no hostname match. Revocation is not looked up, though the CRL and OCSP addresses are listed so you can query them yourself. To see what your server really presents, use the SSL certificate checker.
The pasted text is not a certificate or CSR. Usually a key, a public key or a PKCS#7 bundle was pasted. If the tool detects a private key it shows a warning instead of reading it, because a key should never go into a web page. Paste the block that begins with BEGIN CERTIFICATE or BEGIN CERTIFICATE REQUEST, or convert the file to PEM first.

Part of HostTracker's website monitoring software.