-----BEGIN CERTIFICATE REQUEST----- headers, or raw base64 content.
Awaiting CSR input
Paste a PEM Certificate Signing Request and click Decode// decode and inspect CSR files in one click
Decode and inspect CSR files instantly. View subject, SANs, key algorithm, signature, and all certificate fields — free, browser-safe, no upload needed.
-----BEGIN CERTIFICATE REQUEST----- headers, or raw base64 content.
Awaiting CSR input
Paste a PEM Certificate Signing Request and click DecodeGenerate a CSR with OpenSSL or your server panel. Copy the full PEM output including the header and footer lines.
Paste the CSR into the input box and click "Decode CSR". Results appear instantly on the right.
Review the Subject fields, SANs, and key algorithm to confirm everything matches your certificate requirements.
A Certificate Signing Request (CSR) is a block of encoded text that contains information about the organization and the domain to be secured. It's generated on the server where the certificate will be installed and sent to a Certificate Authority (CA) to issue an SSL/TLS certificate.
Yes. CSRs are designed to be public — they do not contain your private key. Sharing a CSR is safe, as only the corresponding private key (which never leaves your server) can decrypt data encrypted with the issued certificate.
Paste the full PEM-encoded CSR, including the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- header and footer. The tool also accepts raw base64 content without the headers.
SANs allow one certificate to secure multiple domain names. For example, a SAN can include www.example.com, mail.example.com, and example.com in a single certificate. Modern certificates require SANs even for a single domain.
The decoder supports RSA, DSA, and EC (Elliptic Curve) keys. Most modern CSRs use RSA-2048 or RSA-4096, while newer systems may use ECDSA with P-256 or P-384 curves for better performance.
Run: openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr. This generates a 2048-bit RSA private key and CSR. You can then paste the contents of domain.csr into this decoder.
Older CSRs generated without a SAN extension will not include Subject Alternative Names. Many CAs now require SANs — you should regenerate your CSR with a SAN configuration file or use a modern panel that includes them automatically.
A CSR Decoder is an online tool that parses and displays the contents of a Certificate Signing Request (CSR) in a human-readable format. CSRs are encoded in PEM format — a base64-encoded DER structure wrapped in ASCII header lines — which makes them unreadable by humans without proper tooling. A CSR decoder translates this encoded data into clear fields: Common Name, Organization, country code, Subject Alternative Names, key algorithm, key size, and more.
This tool is essential for anyone working with SSL/TLS certificates. Before submitting a CSR to a Certificate Authority (CA), it's critical to verify that the information is correct. A single typo in the Common Name or a missing SAN entry can result in a certificate that doesn't secure the intended domains, leading to browser warnings and failed deployments.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and developer resources — worth checking out.
When you decode a CSR, you'll encounter several standard fields derived from the X.509 distinguished name format:
www.example.com.US, GB, DE.Subject Alternative Names are one of the most important fields to verify in a CSR. SANs allow a single SSL certificate to protect multiple hostnames, IP addresses, email addresses, or URIs. Since 2017, major browsers have required that at least one SAN be present in a certificate for it to be trusted — the Common Name alone is no longer sufficient.
A typical SAN list for a web application might look like:
DNS: example.comDNS: www.example.comDNS: api.example.comWildcard SANs like *.example.com cover all immediate subdomains but not the root domain or deeper subdomains. Always verify SANs match your deployment architecture before submitting to a CA.
The public key embedded in a CSR can use different cryptographic algorithms. The two most common are:
Generate a CSR using OpenSSL with the following commands:
RSA-2048 with new key:
openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr
From an existing private key:
openssl req -new -key domain.key -out domain.csr
ECDSA P-256:
openssl ecparam -name prime256v1 -genkey -noout -out ec.key && openssl req -new -key ec.key -out ec.csr
With SANs (using config file):
Create a config file specifying [alt_names] with DNS.1 = example.com, then reference it with the -config flag.
These three files are often confused by those new to SSL/TLS management:
Before submitting a CSR to your CA, always verify:
Using our CSR Decoder takes only seconds and can save hours of troubleshooting if a mistake is caught before the certificate is issued.