SSL & CSR Decoder
Decode a certificate or CSR in your browser — nothing is uploaded.
Runs 100% in your browser — nothing you paste or generate ever leaves your device.
Accepts .pem / .crt / .cer / .csr / .der — binary DER is detected automatically.
Quick answer
SSL & CSR Decoder parses a certificate or CSR in your browser and shows its subject, SANs, key type, issuer, dates, and extensions, with nothing uploaded. It is the private way to confirm a CSR names the right domains before you buy, or to verify what an issued certificate actually contains.
SSL & CSR Decoder parses an X.509 certificate or a Certificate Signing Request entirely in your browser and shows you everything inside it in human-readable form: subject, issuer, Subject Alternative Names, key type and size, signature algorithm, serial number, validity dates, and extensions. Nothing is uploaded. The certificate or CSR you paste never leaves your machine, which is the critical difference from server-side decoders that receive and log your data. Because a CSR is paired with a private key, decoding one on a remote site is a habit worth breaking.
A CSR (PKCS#10) is the request you generate and hand to a Certificate Authority; it contains the public key and the identity details you want on the certificate, signed by your private key. A certificate is the signed result the CA gives back. This tool decodes both, so you can confirm a CSR names the right domains before you buy, or verify that an issued certificate contains exactly what you expected.
Runs in your browser, nothing uploaded
All parsing happens locally in JavaScript using the ASN.1 and X.509 structure of the file you paste. Your certificate, and especially your CSR, never travels across the network to us or anyone else. Server-side decoders necessarily receive your data and may retain it in logs; for a CSR, which is bound to a private key you are about to certify, that exposure is needless. Doing the work client-side means you can safely inspect production material without leaking it.
PEM vs DER, and what to paste
Certificates come in two encodings. PEM is base64 text wrapped in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines, and it is what you usually copy from a control panel or a .pem/.crt file. DER is the same data in raw binary, common in .der and .cer files and in Windows and Java tooling. Paste PEM text directly; if you have a DER file, it is binary and must be converted to PEM first. A CSR uses the same PEM wrapper but says CERTIFICATE REQUEST instead.
How to read the decoded fields
Start with the SAN list, because that is what clients actually validate the hostname against; the Common Name is legacy and largely ignored. Confirm the key type and size (for example RSA 2048 or ECDSA P-256) and that the signature algorithm is SHA-256 or better. On a certificate, check notBefore and notAfter for the validity window and the issuer to confirm which CA signed it. On a CSR, verify the subject and SANs match every domain you intend to secure before you submit it.
Common uses
Decode a CSR before purchase to catch a typo in the domain or a wrong key size while it is still free to fix. Decode an issued certificate to confirm it covers all the names you paid for. Inspect a certificate someone sent you to see who issued it and when it expires. Check the exact extensions, such as Key Usage and Extended Key Usage, when a certificate is being rejected for the wrong purpose, like a TLS server certificate that lacks the serverAuth usage.
Frequently asked questions
- Is my certificate or CSR uploaded anywhere?
- No. Decoding runs entirely in your browser with JavaScript, so the data you paste never leaves your device. This is the main reason to prefer it over server-side decoders, which receive your file and may log it. It matters most for CSRs, which are tied to the private key you are about to have certified.
- What is the difference between a CSR and a certificate?
- A CSR (Certificate Signing Request, PKCS#10) is what you generate and send to a CA. It holds your public key and the identity you want certified, self-signed with your private key to prove you hold it. The certificate is the CA's signed answer: the same public key and identity, now vouched for by the CA and given a validity period and serial number.
- What is the difference between PEM and DER?
- They are two encodings of the same certificate. PEM is base64 text with -----BEGIN CERTIFICATE----- header lines and is the most common format to copy and paste. DER is the raw binary form, common in .der and .cer files and in Java and Windows tools. Paste PEM directly here; convert DER to PEM first if that is what you have.
- Why does the Common Name not match what browsers use?
- Because modern browsers ignore the Common Name entirely and validate only against the Subject Alternative Names. A certificate must list every hostname it serves in the SAN, including both the bare domain and www if you use both. If a name is missing from the SAN, clients reject it no matter what the Common Name says.
- Can I decode a certificate chain or only one certificate?
- Paste one PEM block at a time for a clean decode of each certificate. If you have a bundle with several -----BEGIN CERTIFICATE----- blocks, decode each separately to inspect the leaf, then the intermediates. To verify that a leaf actually chains to a given intermediate, use the CA Matcher tool instead, which is built for that comparison.
- How do I tell an RSA certificate from an ECDSA one?
- The decoded output shows the public key algorithm and size. RSA appears as a modulus with a bit length like 2048 or 4096. ECDSA shows a named curve such as P-256 (prime256v1) or P-384. ECDSA keys are much smaller for equivalent strength, which is why P-256 is now a popular, faster alternative to RSA 2048 on modern servers.