CSR Decoder

Paste a PEM Certificate Signing Request (CSR) and see every field decoded: the Subject Distinguished Name (CN, O, OU, C, ST, L, email), the public key algorithm and RSA modulus bit-length, and the Subject Alternative Names (SANs) from the extension request. The entire parse runs in your browser using a pure-JS ASN.1 DER reader — nothing is uploaded.

How to use the CSR Decoder

Paste the full PEM block including the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- lines. The tool strips the armor, base64-decodes the DER payload, and walks the ASN.1 structure.

The decoded output shows:

• Subject DN — Common Name (CN), Organization (O), Organizational Unit (OU), Country (C), State (ST), Locality (L), and email address.
• Public Key — algorithm (RSA or EC) and, for RSA, the modulus bit-length (2048, 4096, etc.).
• Subject Alternative Names (SANs) — DNS names and IP addresses from the extension request attribute embedded in the CSR.

Fields that can't be parsed are shown as "unparsed" rather than throwing an error, so partial results are always available. Use the Example button to load a real multi-SAN CSR and see all fields populated.

About Certificate Signing Requests

A Certificate Signing Request (CSR) is a DER-encoded ASN.1 structure defined in PKCS#10 (RFC 2986). It contains the subject's public key, the Distinguished Name the certificate should be issued for, and optional extensions (like Subject Alternative Names). You send a CSR to a Certificate Authority (CA); the CA verifies your domain or organization ownership, signs the public key and subject information with its own private key, and returns the signed certificate. The private key that corresponds to the public key in the CSR never leaves your server.

The format is a three-element SEQUENCE: the CertificationRequestInfo (containing the version, subject DN, SubjectPublicKeyInfo, and optional attributes), the signature algorithm identifier, and the signature over the CertificationRequestInfo. SANs are embedded as an extensionRequest attribute (OID 1.2.840.113549.1.9.14) inside the attributes field. Modern CAs require SANs — the bare CN field is not used for hostname validation in any current browser or TLS library.

Decoding a CSR before submitting it to a CA is an important sanity check. Common mistakes include a wrong Common Name, missing SANs, a 1024-bit RSA key (rejected by all modern CAs), or a CSR generated for the wrong domain. Verifying the decoded output against your intended certificate saves a CA issuance round-trip and, in some cases, money if the CA charges per issuance.

Common use cases

• Pre-submission verification — confirm the CN, SANs, and key size before sending to a CA to avoid a rejected or wrong-domain certificate.
• Support workflow — a customer submits a CSR for a managed certificate; decode it to verify the domain and key before processing.
• Automation audit — verify that a CSR generated programmatically (e.g. by cert-manager, ACME client, or your own scripts) contains exactly the SANs and subject fields you specified.
• Compliance check — confirm the key length meets policy requirements (RSA 2048+ or EC P-256/P-384) before submission to an enterprise CA.
• Training and debugging — understand ASN.1 structure without needing openssl installed; share a CSR with a colleague for review without a CLI.