SSL Certificate & CSR Decoder
Paste a PEM-encoded X.509 certificate or a PKCS#10 CSR and read every field: subject and issuer, validity and expiry, Subject Alternative Names, key type and size, signature algorithm, SHA-1 / SHA-256 fingerprints and the key extensions. It auto-detects whether you pasted a certificate or a request. Everything runs in your browser; nothing is uploaded.
Your certificate is decoded entirely in your browser — it is never uploaded. (This is a decoder: it reads a PEM you paste. To check a live site's cert, you'd need a server — this tool is offline-only by design.)
What this tool is
- A free, in-browser decoder for SSL/TLS certificates (X.509) and certificate signing requests (PKCS#10 CSR) — paste a PEM block and read every field at a glance.
- Auto-detects whether you pasted a certificate or a CSR and shows the right breakdown for each.
- For a certificate: subject and issuer DNs, serial, validity with an expiry countdown and an EXPIRED badge, signature algorithm, public-key type and size, SHA-1 / SHA-256 fingerprints, Subject Alternative Names, key usages, basic constraints and whether it is self-signed.
- For a CSR: the requested subject, public-key info, signature algorithm, requested SANs, and a check of the CSR self-signature.
- Everything is parsed client-side with the jsrsasign library — the PEM you paste never leaves your browser, which matters because a CSR is generated from a private key.
What is an X.509 certificate?
An X.509 certificate is the document behind HTTPS and TLS. It binds a public key to an identity — a hostname, an organisation, sometimes a person — and is signed by a Certificate Authority (CA) that browsers already trust. When you decode one here you see its core fields: the subject (who it is for) and issuer (who signed it) as Distinguished Names broken into CN, O, OU, C and the rest; a serial number; a validity window (notBefore / notAfter); the signature algorithm; and the public key's type and size (RSA 2048, EC P-256, and so on).
SANs, chain of trust and self-signed
The Subject Alternative Names (SANs) list every hostname and IP the certificate is actually valid for — modern TLS ignores the old Common Name and uses SANs, so a mismatch here is a common cause of browser errors. A certificate is trusted because its issuer was signed by a higher CA, and so on up to a trusted root — the chain of trust. When a certificate's subject equals its issuer it is self-signed: fine for internal or development use, but not trusted by browsers out of the box. Basic constraints marks whether a certificate is itself a CA (allowed to sign others), and key usage / extended key usage restrict what the key may do (TLS server auth, client auth, code signing, and so on).
What is a CSR?
A CSR (Certificate Signing Request, PKCS#10) is the request you send to a CA to obtain a certificate. You generate a key pair, keep the private key secret, and build a CSR containing your public key, the identity you want (subject DN and requested SANs), and a self-signature made with your private key to prove you hold it. The CA validates the request and issues a signed certificate. A CSR therefore has a public key and a desired identity but no issuer and no dates — those are filled in by the CA. This decoder verifies the CSR's self-signature when it can.
Why offline matters: this tool decodes a PEM you paste, entirely in your browser — it never connects to any host. That is the safer way to inspect certificate material, especially a CSR, which is created next to a private key. To inspect the live certificate a website is serving, you would need a tool that reaches out to that server; this one deliberately does not, so your data stays local.
Frequently asked questions
What is an X.509 certificate?
An X.509 certificate is the standard digital document that binds a public key to an identity (a domain name, an organisation, or a person). It is what powers HTTPS and TLS. A certificate states who the subject is, who the issuer (the Certificate Authority) is, a validity window (notBefore / notAfter), the subject public key, a list of Subject Alternative Names (the hostnames and IPs the certificate is valid for), extensions such as key usage and basic constraints, and a signature from the issuer over all of that. A browser trusts a site because a CA it already trusts signed the site certificate, forming a chain of trust up to a root. This tool decodes the PEM representation of such a certificate and shows every field in plain language.
What is a CSR, and how is it different from a certificate?
A CSR (Certificate Signing Request, PKCS#10) is what you send to a Certificate Authority to ask for a certificate. You generate a key pair, keep the private key, and put the public key plus the identity you want (subject DN and requested SANs) into the CSR, then sign it with your private key to prove you hold the key. The CA validates your request and issues a certificate. So a CSR is a request that contains a public key and a desired identity but no issuer and no validity dates; a certificate is the signed, dated result that a CA hands back. This decoder auto-detects which one you pasted: a block beginning "-----BEGIN CERTIFICATE REQUEST-----" is a CSR, and "-----BEGIN CERTIFICATE-----" is a certificate.
Is my certificate or CSR uploaded anywhere?
No. All parsing happens locally in your browser using JavaScript (the jsrsasign library) — the PEM you paste is never sent to PlayCISO or any server, and there are no network calls. This is deliberate and it matters most for a CSR: a CSR is generated alongside a private key, and pasting request material into a server-side tool is a habit worth avoiding. Because everything is offline, this is a decoder, not a live checker — it reads a PEM you already have. To inspect the live certificate a website is actually serving you would need a tool that connects to that host, which this one intentionally does not do.
What do the SHA-1 and SHA-256 fingerprints mean?
A certificate fingerprint is a hash (SHA-1 or SHA-256) computed over the entire DER-encoded certificate. It is a short, unique identifier for that exact certificate, shown as colon-separated hex. Fingerprints are used to pin or compare certificates — for example, to confirm that the certificate you are looking at is byte-for-byte the one you expect, or to match it against a value published out of band. SHA-256 is the modern choice; SHA-1 fingerprints are still shown because a lot of older tooling and documentation references them, but SHA-1 should not be relied on for security decisions. This tool computes both locally and you can copy either with one click.