🔎 CSR Decoder
Paste a PKCS#10 Certificate Signing Request below to instantly see its subject fields, SAN entries, public key details, and signature algorithm — decoded entirely inside your browser, nothing uploaded.
What This Decoder Actually Shows You
A CSR is a DER-encoded ASN.1 structure — readable by machines, not by eye. This tool parses that structure directly (the same PKCS#10 format defined in RFC 2986) and pulls out every field a human actually needs to check: the subject details, the SAN list, the public key's algorithm and size, and the signature algorithm used to sign the request. Nothing is sent anywhere — the parsing happens entirely in your browser's JavaScript engine, the same way the CSR Generator builds a CSR without ever transmitting your private key.
Reading the Subject Fields
The Subject block identifies who the certificate is for. This decoder lists each field with its short attribute name (CN, O, OU, C, ST, L) alongside the value exactly as it was encoded in the CSR.
Why the SAN List Matters More Than the Common Name
Since 2020, the CA/Browser Forum's baseline requirements mean browsers only trust domain names actually listed in the Subject Alternative Name extension — a Common Name that isn't also present in SAN won't be treated as covered by the resulting certificate. This decoder lists every SAN entry it finds separately from the subject fields specifically because it's the list worth double-checking most carefully: a missing subdomain here means that subdomain won't be covered by whatever certificate the CA issues from this request.
Public Key Algorithm & Size
The decoder identifies whether the embedded public key is RSA or ECDSA, and reports the actual key size — the real bit-length of the RSA modulus, or the named curve for ECDSA (P-256 or P-384). This matters because some CAs and internal policies have minimum key size requirements, and it's a quick way to confirm a CSR meets them before submission rather than discovering a rejection after the fact.
Reading this off a CSR directly, rather than trusting whatever key size a tool claims to have generated, is a genuinely useful sanity check — key generation code occasionally has bugs, and confirming the actual encoded modulus length matches what was intended takes only a glance once it's decoded.
| Key Type | What's Reported | Typical Minimum |
|---|---|---|
| RSA | Exact modulus bit length (e.g. 2048, 4096) | 2048-bit for public CAs |
| ECDSA | Named curve (P-256, P-384) | P-256 accepted by all modern CAs |
Signature Algorithm & Version
The signature algorithm field shows what hash and signature scheme was used to sign the request — typically SHA-256 with RSA or ECDSA today, since SHA-1-based signing has been deprecated across the CA ecosystem for years. The CSR version field is almost always 0 (meaning PKCS#10 v1), the only version the standard currently defines; anything else usually indicates a malformed or non-standard request worth investigating before submitting it anywhere.
A SHA-1 signature algorithm showing up on a freshly generated CSR is worth treating as a red flag rather than a curiosity — it usually means the tool or library that produced it is old enough to predate current CA baseline requirements, and most public CAs will reject the resulting request outright.
Before You Submit: A Quick Checklist
- Common Name matches the primary domain you intend to secure.
- Every hostname the certificate needs to cover appears in the SAN list — not just the Common Name.
- Key type and size meet your CA's minimum requirements (2048-bit RSA or P-256 ECDSA covers virtually every CA today).
- Signature algorithm uses SHA-256 or stronger, not SHA-1.
- Organization and Organizational Unit fields are correct if you're requesting an OV or EV certificate, since these get manually verified.
Decoding a CSR the Manual Way
The command-line equivalent of what this page does is openssl req -in yourfile.csr -noout -text, which prints the same subject fields, public key details, and requested extensions in OpenSSL's own verbose format. That command has been the standard way to inspect a CSR for decades and remains the most authoritative option if you want output you can pipe into other tooling or a script. This decoder exists for the more common case: a quick visual check without opening a terminal, especially useful on a machine where OpenSSL isn't installed or when reviewing a CSR sent to you by someone else mid-conversation.
What This Tool Doesn't Do
This decoder reads and displays the CSR's structure — it doesn't cryptographically verify that the embedded signature actually matches the public key, and it doesn't check the CSR against any CA's specific policy requirements. For signature verification, openssl req -verify -in yourfile.csr -noout confirms the request is internally consistent (the signature genuinely proves possession of the matching private key). This tool also can't decode an issued certificate — that's a different ASN.1 structure with different fields (issuer, validity dates, CA signature) — the Certificate Decoder handles that structure specifically, or use the SSL Certificate Checker for a live lookup against a server.
Real-World Scenarios
Summary
A CSR is a small but easy-to-misread structure, and the gap between "the file looks right" and "the file is right" is exactly what a decoder closes. Checking the subject fields, SAN list, key size, and signature algorithm before submission takes under a minute and avoids the much slower cycle of catching a mistake after a CA has already started processing the request.
Related Reading
For generating a new CSR from scratch, see the CSR Generator. For checking an already-issued certificate's issuer, validity, and history, see the SSL Certificate Checker. For the mechanics of TLS versions and cipher negotiation once your certificate is live, see TLS/SSL Protocol & Certificate Types and How to Disable TLS 1.0 and 1.1.