DevTools Logo

CSR Decoder

CSR Decoder

Paste a PEM Certificate Signing Request to inspect its subject, public key, signature and SANs — entirely in your browser

Certificate Signing Request

Paste the PEM (-----BEGIN CERTIFICATE REQUEST-----) or raw base64 DER

Decoding happens locally. Your CSR never leaves this browser.

Examples

Decoding a standard example.com RSA-2048 CSR

Input
-----BEGIN CERTIFICATE REQUEST-----
MIIDLzCCAhcCAQAwgZ4xCzAJBgNVBAYTAlVT...m4rD
-----END CERTIFICATE REQUEST-----
Output
Subject:    C=US, ST=California, L=San Francisco, O=Example Inc,
           OU=Engineering, CN=example.com, emailAddress=admin@example.com
Version:    1 (0x0)
Public key: rsaEncryption — 2048 bit (Modulus c4:05:e6:2a:…; Exponent 65537)
Signature:  sha256WithRSAEncryption, 256 bytes
SANs:       DNS:example.com, DNS:www.example.com, DNS:api.example.com

The sample CSR bound to the bundled sample button. The decoder walks the PKCS#10 structure client-side and surfaces a complete summary — subject DN, public-key algorithm and size, signature algorithm and length, and the SubjectAltNames that modern browsers actually validate against.

Detect an EC key from a P-256 CSR

Input
-----BEGIN CERTIFICATE REQUEST----- … ecPublicKey, prime256v1 … -----END CERTIFICATE REQUEST-----
Output
Subject:    CN=example.com
Version:    1 (0x0)
Public key: EC — 256 bit (curve prime256v1, public point 04:8d:… )
Signature:  ecdsa-with-SHA256, 64 bytes
SANs:       DNS:example.com

The decoder recognises the algorithm OID and reports the named curve rather than a bit length. Use the type label (RSA vs EC) to confirm a CSR matches the cipher suite a CA or load balancer expects before paying for a certificate.

Empty input is handled, not crashed

Input
(empty textarea)
Output
Empty state — paste a CSR on the left, or click Load sample

The decoder treats blank input as a no-op and surfaces the friendly 'paste or load sample' message. Invalid PEM triggers a destructive error block quoting the ASN.1 parsing failure so you can fix the exact line.

About this tool

A Certificate Signing Request (CSR) is the PEM-encoded PKCS#10 file you generate (with openssl req or a similar tool) and hand to a Certificate Authority when you want an SSL/TLS certificate. It binds the subject name you want on the certificate to a public key, and is signed by the matching private key. Before sending it off — or paying for a certificate — it's worth confirming exactly what's inside it.

This decoder parses the request entirely in your browser using a small, dependency-free ASN.1/DER reader. It walks the CertificationRequest structure and surfaces the version, every subject attribute (CN, O, OU, locality, state, country, email), the public key with its algorithm and size, the signature algorithm and length, the Subject Alternative Names (DNS, IP, URI, email), and any other requested extensions.

It handles both RSA keys (reporting the modulus length and exponent) and elliptic-curve keys (identifying the curve), and reads the SubjectAltName extension that modern browsers actually rely on. Nothing is uploaded — the request is processed only on your device, which makes the tool suitable for inspecting real, production CSRs.

How to use

  1. Paste your CSR

    Paste the PEM (-----BEGIN CERTIFICATE REQUEST-----) or the raw base64 DER into the left pane, or click Load sample to try one. Decoding happens instantly as you type.

  2. Read the subject and key

    Check the subject attributes match the identity you want certified, and confirm the public key is RSA 2048-bit+ or an EC P-256/P-384 key with a modern signature algorithm.

  3. Verify the SAN list

    Modern browsers validate the Subject Alternative Names, not the Common Name. Make sure every domain (and IP, if used) that should appear on the certificate is listed under SANs.

  4. Copy the summary

    Use the copy button to save a plain-text summary of the decoded fields for your records or to share with whoever issues the certificate.

Use cases

Inspecting a CSR before sending it to a CA

Open the CSR, confirm the Common Name and every Subject Alternative Name match the domains you intend to certify, and verify the algorithm and key size are still considered strong. Cheaper than waiting for a CA to reject the request.

Onboarding a new domain or hostname

When a teammate generates a CSR with a name like api.example.com, paste it in the decoder and confirm the SAN list contains every DNS entry that should appear on the issued certificate — both bare and wildcard form.

Auditing key strength across services

Drop each service's CSR into the decoder and confirm every request uses RSA 2048-bit+, ECDSA P-256/P-384, or a stronger algorithm — and that no service is still on RSA 1024-bit or sha1WithRSAEncryption.

Writing tooling that needs the public key

After decoding, copy the subject DN and the public-key algorithm/size block for documentation or use the Modulus/Exponent detail fields as a fingerprint for inventory scripts.

Decoded fields

FieldWhat it means
VersionPKCS#10 request version (normally 0, shown as version 1)
SubjectThe name to be certified: CN, O, OU, locality, state, country, email
Public keyAlgorithm (RSA / EC), key size or curve, modulus or public point
Signature algorithme.g. sha256WithRSAEncryption or ecdsa-with-SHA256
Subject Alternative NamesDNS, IP, URI and email entries that will appear on the certificate
ExtensionsAny other requested extensions, such as keyUsage or extKeyUsage

Decoding is 100% client-side — the CSR never leaves your browser.

Common mistakes

Mistake:Sending a CSR with an outdated signature algorithm (sha1, md5) to a CA.

Fix:Modern CAs (and browsers) reject SHA-1-signed CSRs. Regenerate the CSR with -sha256 (OpenSSL) or your PKI tool's modern default and re-decode here to confirm the signature algorithm before submission.

Mistake:Trusting only the Common Name on the certificate.

Fix:Modern browsers validate against the SubjectAltName extension. Use the SAN list from the decoder — not just CN — to confirm every domain and wildcard the certificate will cover.

Mistake:Using a 1024-bit RSA key in a CSR because the legacy app demands it.

Fix:1024-bit RSA has been considered insecure since 2013. Generate a 2048-bit RSA or a 256-bit EC key instead — both fit comfortably in the same Certificate Signing Request format.

Mistake:Pasting a certificate, a public key, or a chain into the CSR decoder.

Fix:The decoder expects the PKCS#10 request (-----BEGIN CERTIFICATE REQUEST-----). A certificate (-----BEGIN CERTIFICATE-----) parses as a different ASN.1 root and will throw a friendly error pointing at the parser.

Mistake:Treating 'signatureLength 256 bytes' as a guarantee that the key is strong.

Fix:Signature length is algorithm-dependent — RSA 2048 produces 256-byte signatures and EC P-256 produces 64-byte signatures. Cross-check signatureLength against the Public key algorithm field rather than reading length in isolation.

Frequently asked questions

References & standards