CSR Decoder: Decode & Verify CSR Files Online

A Certificate Signing Request (CSR) is Base64-encoded text that is essentially unreadable to humans. Before you submit it to a Certificate Authority — or if you have received a CSR from a developer to review — decoding it lets you verify every field inside. This guide explains how to decode a CSR, what each field means, and what to do if something is wrong.

What Is CSR Decoding?

CSR decoding (sometimes called CSR parsing or CSR reading) converts the Base64-encoded CSR data into a human-readable format. The underlying format is PKCS#10, a standard defined in RFC 2986. A CSR decoder extracts:

• The Distinguished Name (DN) fields: Common Name, Organization, Location, Country
• The public key type and size
• The signature algorithm used to sign the request
• Any extensions included (Subject Alternative Names)

The result is a readable breakdown you can audit in seconds.

The Difference Between a CSR Decoder and a CSR Checker

These two tools are related but serve different purposes:

• CSR Decoder — decodes and displays all fields in the CSR. Shows you what is inside.
• CSR Checker — verifies the CSR is structurally valid (signature intact, encoding correct) and confirms it can be accepted by a CA.

Our CSR Decoder performs both: it decodes all fields and validates the CSR structure simultaneously.

How to Decode a CSR Using the Free Online Tool

1. Open the CSR Decoder.
2. Paste your complete CSR text. It must start with -----BEGIN CERTIFICATE REQUEST----- and end with -----END CERTIFICATE REQUEST-----.
3. Click Decode CSR.
4. Review all decoded fields in the output.

To decode via OpenSSL command line:

openssl req -in yourdomain.csr -noout -text

CSR Fields Explained in Detail

Common Name (CN)

The most critical field. This is the primary domain the certificate will cover. Must be the exact FQDN: yourdomain.com, www.yourdomain.com, or *.yourdomain.com for wildcard. Modern browsers look at the SAN field primarily, but the CN is still required.

Organization (O)

Your legal business name. For OV and EV certificates, the CA will verify this against official business registration records. It must match exactly — including punctuation and abbreviations (Ltd vs Limited). For DV certificates and personal sites, this can be your name or any reasonable identifier.

Organizational Unit (OU)

Optional. Traditionally used for the department (IT Department, Web Security). Many CAs are phasing out support for this field in issued certificates. You can leave it blank.

Locality (L)

The city or town where your organization is legally registered. Do not abbreviate — write the full city name.

State or Province (ST)

The state, province, or region. Write the full name, not the abbreviation: "California" not "CA", "Maharashtra" not "MH". For countries without states, use the country name or region.

Country (C)

Two-letter ISO 3166-1 alpha-2 country code: US (United States), GB (United Kingdom), IN (India), DE (Germany), AU (Australia). This field must be exactly two capital letters.

Public Key

The decoded CSR shows the public key type (RSA or ECDSA) and size (2048-bit, 4096-bit, P-256, P-384). All CAs require a minimum of RSA 2048-bit or ECDSA P-256. Keys smaller than RSA 2048-bit will be rejected.

Signature Algorithm

The algorithm used to sign the CSR request itself. Common values: sha256WithRSAEncryption for RSA keys, ecdsa-with-SHA256 for ECDSA keys. SHA-1 signature algorithms are deprecated and will be rejected.

Subject Alternative Names (SANs)

If the CSR includes SAN extensions, they appear here. SANs list additional domains the certificate should cover. Many CAs let you specify SANs in their ordering form even if the CSR does not include them. Check with your CA whether SANs should be in the CSR or specified separately.

What to Look for When Reviewing a CSR

When decoding a CSR — whether your own or from a colleague — check these items:

• Is the Common Name the exact domain intended?
• Does the Organization name match the registered business name exactly?
• Is the Country code correct (two capital letters)?
• Is the key size 2048-bit or larger?
• Is the signature algorithm SHA-256 or better?
• If SANs are needed, are they listed?

If the Decoded CSR Contains Errors

CSR data is encoded and signed — you cannot edit a CSR after it is generated. If any field is wrong, you must generate a new CSR. Use our CSR Generator to create a correct CSR, then verify it again with the decoder before submitting to the CA.

Related SSL Tools

• CSR Generator — generate a new CSR with correct fields
• CSR Checker — validate that your CSR is structurally correct
• Certificate Decoder — decode the issued certificate once the CA sends it
• Certificate Key Matcher — match the certificate to your private key
• SSL Checker — verify final installation on your server

Frequently Asked Questions

Is a CSR and a certificate the same thing?

No. A CSR is the request you send to the CA before getting a certificate. The CA processes your CSR and issues a certificate. The CSR contains your public key and identity; the certificate is the CA's signed attestation of that identity.

Can I use any CSR decoder to read my CSR?

Yes. The PKCS#10 format is a universal standard. Any decoder — online tools, OpenSSL, or programming libraries — will decode any valid CSR. The decoded data will be identical regardless of which tool you use.

My CSR decoder says "invalid CSR" — what could be wrong?

Common causes: the CSR text was copied with missing characters (especially at the start or end), extra line breaks were inserted, or the header/footer lines were modified. Try copying the raw CSR from the original source again. If it was generated by an online tool, regenerate it.

Can I decode a CSR to extract the private key?

No. The private key is mathematically related to the public key in the CSR but cannot be derived from it. The CSR contains only the public key. The private key is a separate file that was generated alongside the CSR and never embedded in it.