CSR Decoder: Decode CSR Online, Free & Instant

A CSR decoder reads a PEM-encoded Certificate Signing Request and shows what is inside it: the common name, organization, location, key type and size, signature algorithm, and any Subject Alternative Names. Developers, sysadmins, and SSL buyers use it to catch mistakes before sending the request to a certificate authority.

What Is a Certificate Signing Request?

A Certificate Signing Request (CSR) is a block of encoded text you send to a certificate authority (CA) when you order an SSL/TLS certificate. It carries your public key, the identity details you want on the certificate, and a signature made with your private key that proves you hold the matching key.

Most CSRs use the PEM format: Base64 text wrapped between -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST-----. Because the body is encoded, you cannot read it by eye. A private key is never part of a CSR, so decoding one exposes only the details you chose to submit.

This page is about certificate requests only. It has nothing to do with CSRF tokens (a web attack defense) or with corporate social responsibility, even though the abbreviations look alike in search results.

How to Use the CSR Decoder

You decode a request by pasting its text into one box and pressing one button. The steps below match the fields on this page.

1. Locate your CSR file. It usually ends in .csr or .pem and opens in any plain text editor.
2. Copy the whole text, including the BEGIN and END lines. Missing even one dash in those lines can cause a parse error.
3. Paste it into the box labeled Certificate Signing Request (CSR).
4. Click Decode CSR.
5. Review the result: the subject table, the Technical Details section, the Subject Alternative Names list, and the signature status shown next to the "CSR decoded" message.
6. If anything is wrong, build a corrected request with the CSR generator and decode that one before you order.

The box accepts up to 256 KB of text, far more than any normal CSR needs.

Worked Example: Checking a CSR Before You Order

Say you generated a CSR for an online store and want to confirm it before paying for a certificate. You paste it in and click Decode CSR. The tool returns:

• Common Name: www.example.com
• Organization: Example Store LLC
• City: Austin, State / Province: Texas, Country: US
• Key Type: RSA, Key Size: 2048 bit
• Signature Algorithm: sha256WithRSAEncryption
• Subject Alternative Names (2): example.com and www.example.com

This is a healthy request. The hostname is spelled correctly, the RSA key is 2048 bits, the signature uses SHA-256, and both the bare domain and the www version are covered. Now imagine the Subject Alternative Names section is missing and you need both names. You would stop here, regenerate the CSR with both hostnames included, and decode again. Finding that now costs you a minute. Finding it after issuance can cost you a reissue and a delay.

How Do You Read and Act on the Decoded Results?

Each part of the output answers a different question: who the certificate is for, how strong the key is, which hostnames it covers, and whether the request is intact. Use the table as a quick checklist.

Subject details

The subject table lists whichever of these fields the CSR contains: Common Name, Organization, Organizational Unit, Email Address, Address, City, State / Province, Postal Code, and Country. Fields that are not in the request simply do not appear. For organization-validated certificates, spelling and legal name matter because the CA compares them with official records. Domain-validated certificates usually ignore most of these fields.

Technical details

Key Type tells you whether the request uses RSA, EC, or another algorithm. Key Size is shown in bits. A 2048-bit RSA key is the widely accepted minimum for public certificates, and 3072 or 4096 bits are common choices when you want extra margin. SHA-1 signatures are deprecated for public certificates, so a CSR showing one should be replaced.

Subject Alternative Names

Modern browsers match the hostname you visit against the Subject Alternative Names (SANs), not just the common name. This section shows a count and each name found in the request. If you plan to secure example.com, www.example.com, and api.example.com on one certificate, all three should appear here.

Signature status

The status next to "CSR decoded" tells you whether the request signature checks out. "Invalid CSR signature" means the request is damaged or malformed and you should not use it. "Signature unverified" means the CSR was decoded, but its signature algorithm is not one this page can verify. A passing status means the request is internally consistent.

Who Needs to Decode a CSR?

Anyone who creates, orders, or troubleshoots SSL/TLS certificates benefits from seeing what is inside a request before it leaves their hands.

• Sysadmins and DevOps engineers confirm that a CSR created on a server contains the right hostname and key size before filing a ticket.
• Web developers verify that a CSR from a hosting panel includes the SANs the application needs.
• Agencies and consultants inspect a CSR a client emailed over, without needing access to the client's server.
• Security reviewers audit requests for weak keys or outdated signature algorithms.
• Anyone asking how to read a CSR file on a machine without command-line tools can paste it here instead.

Best Practices and Troubleshooting

A few habits prevent most certificate ordering problems, and a few quick checks solve most decoding errors.

• Decode before every order. It takes seconds and catches typos in the hostname or organization name.
• Fix "Unable to parse" errors by checking the text. Make sure the BEGIN and END lines are intact, there are no extra characters before or after, and the text was copied in full. Line breaks inside the Base64 body are fine.
• Paste the right file. A block starting with BEGIN CERTIFICATE is an issued certificate, not a request. Use the certificate decoder for that. Never paste a private key into any online tool.
• Expect no SANs on some requests. Some CSRs list only a common name. Many CAs add the SAN themselves at order time, but confirm that before relying on it.
• Match the key to the certificate later. After the CA issues your certificate, run it through the certificate key matcher with your private key before installing.
• Use a second check if you want one. The Check CSR page offers a separate validation pass for requests and certificate files.
• Prefer the command line? openssl req -in your.csr -noout -text -verify prints similar details in a terminal.

What Are the Limits of a CSR Decoder?

Decoding shows what a request says. It does not guarantee that a CA will issue the certificate.

• The CA still has to validate that you control the domain, and for OV or EV certificates, that your organization exists.
• The tool reads PEM text. A binary DER file must be converted to PEM first.
• It decodes one CSR at a time, so paste each request separately.
• The subject table covers the common identity fields. Unusual or custom attributes may not be listed.
• It cannot tell you whether a CSR matches a particular private key. Use the key matcher for that.

If you want to see exactly what your certificate authority will receive, paste your request into the box above and click Decode CSR. When you need a fresh request, the security and encryption tools collection has related generators and checkers for the next step.