CSR Decoder (Certificate Signing Request)

Decode a PEM CSR (Certificate Signing Request) instantly to review the CN, SAN, organization, and public key algorithm before submitting to a CA. Free, no signup.

What is a CSR decoder?

A CSR decoder lets you decode a PEM-formatted CSR (Certificate Signing Request) and instantly see the Subject fields (CN, organization, and so on), SAN (Subject Alternative Name) entries, public key algorithm, and signature algorithm it requests. Paste your CSR and this free tool shows you exactly what you're about to submit, so you can catch mistakes before a certificate authority (CA) ever sees them.

This is a companion to our X.509 Certificate Decoder, but the two tools solve different problems. The X.509 decoder inspects certificates that a CA has already issued, while this CSR decoder looks at the request itself, before a CA has reviewed or issued anything. That makes it the right tool for a last check right after generating a CSR, or before you regenerate a private key and start the process over.

How to decode a CSR

Paste your PEM-formatted CSR Copy the full block starting with "-----BEGIN CERTIFICATE REQUEST-----" and paste it directly into the input field.
Paste multiple CSRs if you need to You can paste several CSRs at once; each PEM block is detected and decoded separately.
Click "Decode" Once you see how many CSRs were detected, click the button to have them parsed server-side.
Review the results The Subject, SAN entries, public key algorithm, and more are displayed in a clear summary for each CSR.

Tips for getting more out of it

Before submitting, double-check that every hostname you actually want issued appears in both the CN (Common Name) and the SAN list. A missing SAN entry almost always means a costly reissue later.
This is also a good moment to confirm the public key isn't weaker than it should be — for example RSA under 2048 bits or an EC curve your CA no longer accepts. Catching this now avoids having the request rejected during review.
If you plan to reuse the same CSR across multiple servers, re-verify that the organization name and domains in the Subject and SAN actually match what you intend to request.
Keep in mind this tool only shows you what the CSR is requesting. The CA's final decision on which SANs get issued can still differ from what was submitted.

When this tool comes in handy

Final check before buying an SSL certificate

Confirm the CN and SAN entries you entered when generating the CSR are correct before you pay for a certificate.

Verifying an internal CSR-generation process

Check that a CSR produced with openssl req or a similar command matches what was intended, even if you're not comfortable reading command-line output directly.

Reviewing an old CSR you have on file

Safely inspect the contents of an archived CSR file without ever touching the associated private key.

Catching missing SANs on multi-domain certificates

When requesting a single certificate that covers several hostnames, spot any missing SAN entries before you submit.

Glossary

CSR (Certificate Signing Request): A package of data — a public key plus requested identity information such as Subject and SAN — that you submit to a CA when asking it to issue a certificate.
CA (Certificate Authority): A trusted third party that reviews the contents of a CSR and, if everything checks out, issues the actual SSL/TLS certificate.
CN (Common Name): A Subject field naming the primary host or service the certificate is for. Browsers used to validate against the CN alone, but modern browsers rely on SAN instead.
SAN (Subject Alternative Name): An extension field listing every hostname or IP address the certificate should be valid for. At the CSR stage, it's carried inside what's called "Requested Extensions."
Requested Extensions: The set of attributes an applicant asks the CA to include at issuance time. SAN entries live here, but a CA is not obligated to honor them exactly as requested.
Public key algorithm: The scheme used to generate the public key embedded in the CSR — typically RSA or EC (elliptic curve cryptography) — where key length or curve choice determines cryptographic strength.

Frequently asked questions

Your CSR is sent to our server once to be parsed, but it isn't stored or permanently logged afterward. A CSR never contains a private key, but if the requested details themselves are sensitive, avoid pasting them into any online tool.

No. This tool only accepts CSRs — text starting with "-----BEGIN CERTIFICATE REQUEST-----". Never paste a private key into any online tool, ever.

This usually means the BEGIN/END lines are missing, the Base64 body is corrupted or truncated, or the pasted text is actually a certificate or private key rather than a CSR.

The X.509 Certificate Decoder reads certificates a CA has already issued. This tool reads the CSR itself — the request you submit before issuance — so fields like expiration date and fingerprint don't apply here, since a CSR doesn't have them.

Usually yes, but the CA has the final say. Some CAs ignore the SAN list in the CSR entirely and instead issue based on whatever you specified in their order form or web portal.

Side Note — Why does a CSR contain a signature?

Look closely at a decoded CSR and you'll notice that, right after the Subject and public key information, there's a signature algorithm and a signature value. That can seem a little strange at first: why would a document asking a CA to "please vouch for me" already contain a signature of its own? The answer is a concept called Proof of Possession. The applicant signs the entire CSR body — Subject, public key, and all — using the private key that corresponds to the public key named in that same CSR. That signature is effectively saying "I genuinely hold the private key that matches this public key." Anyone trying to submit a CSR containing someone else's public key would be unable to produce a valid signature without that person's private key, which is exactly what stops impersonation at the request stage.

The CSR format was originally standardized in 1986 as PKCS#10, part of the PKCS (Public-Key Cryptography Standards) family developed by RSA Security. The IETF later re-published it as RFC 2986, but in practice, engineers still refer to it as "PKCS#10" far more often than by its RFC number. It's an unglamorous piece of the TLS ecosystem, easy to overlook, yet every certificate in existence traces back to one of these requests.

Standardizing SAN support inside a CSR's Requested Extensions is actually a fairly recent development in the history of PKI. The original PKCS#10 specification only really anticipated Subject and CN fields, so as multi-domain and wildcard certificates grew popular, individual CAs came up with their own ad-hoc ways of accepting SAN data. Today, mainstream tools like OpenSSL support a standardized approach defined in RFC 2985, known as the Extension Request attribute, for embedding SAN entries in a CSR — and this is precisely the standard location (the extensionRequest attribute inside Attributes) that this tool reads SAN data from.

Browse all trivia