{ CSR Decoder }

// 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.

Paste the full PEM block including -----BEGIN CERTIFICATE REQUEST----- headers, or raw base64 content.
🔐

Awaiting CSR input

Paste a PEM Certificate Signing Request and click Decode

HOW TO USE

  1. 01
    Get your CSR

    Generate a CSR with OpenSSL or your server panel. Copy the full PEM output including the header and footer lines.

  2. 02
    Paste & Decode

    Paste the CSR into the input box and click "Decode CSR". Results appear instantly on the right.

  3. 03
    Inspect & Verify

    Review the Subject fields, SANs, and key algorithm to confirm everything matches your certificate requirements.

FEATURES

Subject Fields SAN Detection Key Algorithm Raw Output RSA & EC Keys PEM Parsing

USE CASES

  • 🔧 Verify CSR before submitting to a CA
  • 🔧 Inspect SANs for multi-domain certificates
  • 🔧 Confirm key type and bit length
  • 🔧 Audit CSR fields for compliance
  • 🔧 Debug certificate request issues

WHAT IS A CSR?

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.

RELATED TOOLS

FREQUENTLY ASKED QUESTIONS

Is it safe to paste my CSR here?

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.

What format should my CSR be in?

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.

What is a Subject Alternative Name (SAN)?

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.

What key algorithms are supported?

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.

How do I generate a CSR with OpenSSL?

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.

Why does my CSR show no SANs?

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.

What Is a CSR Decoder?

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.

How to Read a CSR: Key Fields Explained

When you decode a CSR, you'll encounter several standard fields derived from the X.509 distinguished name format:

Understanding Subject Alternative Names (SANs)

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:

Wildcard 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.

Key Algorithms: RSA vs ECDSA

The public key embedded in a CSR can use different cryptographic algorithms. The two most common are:

Common CSR Generation Commands

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.

CSR vs Certificate vs Private Key

These three files are often confused by those new to SSL/TLS management:

Verifying a CSR Before Submission

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.

☕