CSR Decoder Online — Free Certificate Signing Request Inspector

Paste a PEM Certificate Signing Request and inspect every field — Subject DN, Subject Alternative Names, public key algorithm, signature algorithm, challenge attributes. ASN.1 parsed entirely in your browser.

PEM CSR Input

Decoded Result

Click Decode to parse a pasted CSR. Use Load Sample to try with a real PEM CSR.

What is a CSR Decoder?

A CSR decoder parses the ASN.1 DER structure inside a PEM Certificate Signing Request and surfaces every field a Certificate Authority will see — Subject Distinguished Name, Subject Alternative Names, public key algorithm and size, signature algorithm, and any attributes. It lets you verify a CSR matches what you intended to submit before paying for a certificate.

CSRs are deceptively opaque — a wall of base64 hides whether you forgot the SAN list, used the wrong key algorithm, or fat-fingered the Common Name. Decoding catches mistakes in seconds; a CA rejection (or worse, a wrong-name cert) takes hours.

How to decode a CSR — 4 steps

Copy the PEM block. Open server.csr and copy from -----BEGIN CERTIFICATE REQUEST----- through -----END CERTIFICATE REQUEST-----, inclusive.
Paste it. Drop the block into the input box. Whitespace, line endings, and trailing newlines are tolerated.
Click Decode. The browser walks the ASN.1 DER tree and extracts Subject, SAN, key, and signature info into a styled card.
Verify against expectations. Confirm CN, every SAN, and the key algorithm. Mismatch? Regenerate the CSR before sending it to the CA.

Sample input

-----BEGIN CERTIFICATE REQUEST-----
MIIC2zCCAcMCAQAwgZUxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
MRYwFAYDVQQHDA1TYW4gRnJhbmNpc2NvMREwDwYDVQQKDAhBY21lIEluYzELMAkG
A1UECwwCSVQxFDASBgNVBAMMC2V4YW1wbGUuY29tMSMwIQYJKoZIhvcNAQkBFhRh
ZG1pbkBleGFtcGxlLmNvbS5sbA...
-----END CERTIFICATE REQUEST-----

# Decoded fields
Subject:    CN=example.com, O=Acme Inc, OU=IT, L=San Francisco, ST=California, C=US
SANs:       DNS:example.com, DNS:www.example.com
Public key: RSA, 2048 bits
Signature:  sha256WithRSAEncryption

Full Field Extraction

Subject DN, every SAN, public key algorithm and size, signature algorithm, and attributes — surfaced from the ASN.1 DER bytes.

Pure JavaScript ASN.1

A custom DER walker handles SEQUENCE, SET, OID, UTF8String, IA5String, OCTET STRING, INTEGER, NULL — no native binaries, no WASM.

Stays in Browser

CSRs are public, but the parsing still happens locally — open DevTools Network and confirm zero requests on Decode.

Common use cases

check_circleVerifying a CSR before submitting to a commercial CA (DigiCert, Sectigo, GlobalSign)
check_circleConfirming SAN list matches expected hostnames for multi-domain certs
check_circleAuditing CSRs from automation pipelines (Terraform, Ansible, Vault PKI)
check_circleCatching wrong-key-algorithm CSRs (e.g. RSA-1024 left over from legacy templates)
check_circleInspecting CSRs delivered via SCEP, CMP, or ACME for enrolment debugging
check_circleVerifying the Subject DN format matches a strict CA template (OV/EV)
check_circleReviewing third-party CSRs before signing them with an internal CA
check_circleTeaching engineers to read ASN.1 by visualising what openssl req actually wrote

Why decode CSRs?

A CSR is the moment you commit a public key and a list of names to your Certificate Authority. Once signed, that cert lives for 90 days (Let's Encrypt) to 13 months (commercial DV/OV). Catching a missing SAN or wrong organisation name before you submit avoids paying a re-issue fee, replacing the cert on every load balancer, and waiting on DNS propagation again. The cheapest CSR review is the one you do in 10 seconds in your browser before you click submit.

Privacy & security

CSRs contain only public information — the public key plus the names you wish to certify. The matching private key is never asked for here. Decoders only parse public information. We never see private keys.

Need other SSL/TLS helpers?

Decode the issued certificate with the X.509 inspector, build the openssl command that produced this CSR, or generate a server-side TLS config — all browser-side.

SSL Certificate Decoder OpenSSL Command Generator SSL Config Generator

Frequently Asked Questions

What is a CSR?

A Certificate Signing Request is a PEM-encoded ASN.1 structure containing a public key, a Distinguished Name (Common Name, organisation, country) and an optional set of attributes — most commonly an extensionRequest holding the desired Subject Alternative Names. You generate the CSR alongside a private key and send the CSR to a Certificate Authority for signing.

Is it safe to paste a CSR online?

Yes. A CSR contains only public material — your public key plus the names you wish to certify. The private key never leaves the host where it was generated. Even so, this decoder runs entirely in your browser, so the CSR text never leaves the tab — verify in DevTools Network.

What fields are required?

Common Name (CN) is the only field every CA insists on, and even that is being deprecated in favour of SAN-only certificates. Organisation (O) and Country (C) are required for OV/EV certs. For DV (Domain Validation) certs like Let’s Encrypt, only the SAN list is validated — the rest of the Subject DN is ignored.

How can I verify the SAN list?

Click Decode and look at the Subject Alternative Names section. Every name (DNS, IP, email, URI) the CA will validate appears here. If a name is missing, the CSR was generated without -addext or without a [req_ext] section in the openssl config — regenerate before submitting.

Can I extract the public key?

The decoder reports the algorithm (RSA, ECDSA, Ed25519) and bit size, which is what you usually need to confirm. To extract the actual public-key bytes, run openssl req -in csr.pem -noout -pubkey on a host with openssl installed — exporting the bytes here would clutter the UI without adding value.

What is the challenge password?

A legacy SCEP attribute originally used to authorise enrolment. Modern public CAs ignore it. If openssl prompted you for "A challenge password" during csr generation and you typed something, that string ends up in this field — empty is the safe default.

Can I decode encrypted CSRs?

CSRs themselves are never encrypted — only the corresponding private key may be. If your file starts with -----BEGIN ENCRYPTED PRIVATE KEY----- you have pasted the wrong artefact. Look for -----BEGIN CERTIFICATE REQUEST----- specifically.

Why does my CSR show different fields than I entered?

OpenSSL silently truncates Subject fields longer than 64 characters and rejects characters outside the chosen string type (PrintableString does not allow @, *, _). It also normalises Country codes to uppercase 2-letter ISO. If a field looks wrong here, regenerate with -utf8 and double-check the -subj string.