Your files never leave your device. All processing happens locally in your browser.
How do I decode a CSR (certificate signing request) online?
Paste your PEM CSR (the block that starts with -----BEGIN CERTIFICATE REQUEST-----) into the CSR Decoder and it is parsed instantly in your browser. A hand-written PKCS#10 / ASN.1 engine reads the Subject distinguished name, the public key type and size, the signature algorithm and the requested attributes — Subject Alternative Names, key usage, extended key usage and basic constraints — then verifies the CSR’s own self-signature with the Web Crypto API and shows a SHA-256 fingerprint. Everything runs locally; nothing is uploaded, and your private key is never involved.
Reads the Subject DN (CN, O, OU, C, ST, L, emailAddress) and the public key (RSA bits or EC curve)
Decodes the extensionRequest attribute: SANs (DNS / IP / email / URI), key usage, EKU, basic constraints
Verifies the self-signature over certificationRequestInfo (RSA PKCS#1 v1.5 and ECDSA) via Web Crypto
SHA-256 fingerprint of the DER; raw ASN.1 tree view; copy or download the read-out
Everything runs in your browser (PKCS#10 / RFC 2986); the CSR is never uploaded
What is
CSR Decoder
A CSR decoder is a tool that takes the Base64 PEM or binary DER encoding of a PKCS#10 Certificate Signing Request (RFC 2986) and parses its ASN.1 structure into human-readable fields — the Subject distinguished name, the subject public key, the signature algorithm, and the requested attributes and extensions such as Subject Alternative Names, key usage and basic constraints. A client-side decoder does this entirely in the browser and can additionally verify the request’s self-signature, which proves the applicant holds the matching private key. A CSR states what is being requested; the issuing certificate authority decides what is actually granted.
Security & Privacy
Related terms
PKCS#10RFC 2986ASN.1DERPEMSubject Alternative NamecertificationRequestInfoextensionRequestpublic key infrastructurecertificate authorityRSAECDSA
Frequently Asked Questions
No. The CSR is base64-decoded, parsed and self-signature-verified entirely in your browser with the Web Crypto API — nothing is uploaded.
The CSR Decoder is 100% client-side. Your PEM text is decoded and walked by a local PKCS#10 / ASN.1 engine written in JavaScript, and the self-signature and SHA-256 fingerprint are computed by your browser’s Web Crypto API (crypto.subtle). There is no backend, upload, database or CDN in the processing path and no analytics. This matters because a CSR can expose internal hostnames, organisational units and email addresses; here those details never leave your device, the tool works offline once cached, and closing the tab erases everything.
No. A CSR only proves you hold the private key and states what you are requesting. The certificate authority decides what is actually issued.
A PKCS#10 CSR is self-signed, so a valid self-signature proves the applicant possesses the private key that matches the enclosed public key — nothing more. It does not establish trust, and it does not guarantee issuance. The CA runs its own validation and policy checks and may add, drop or override fields, so the final certificate can differ from what the CSR requested. This tool reads and self-signature-checks the request; it does not submit it or contact any CA.
No — and you should never paste one. A CSR contains only your public key; the private key is never part of it and is not needed here.
A certificate signing request carries your Subject information and your public key, and is signed with the corresponding private key to prove possession. The private key itself is never included in the CSR and is never required to decode or verify one. Keep your private key (the -----BEGIN PRIVATE KEY----- / RSA PRIVATE KEY file) secret and offline; this tool only ever needs the -----BEGIN CERTIFICATE REQUEST----- block.
RSA PKCS#1 v1.5 (SHA-1/256/384/512) and ECDSA on P-256, P-384 and P-521. RSASSA-PSS, Ed25519, DSA and SHA-224 are decoded but shown as unsupported for in-browser verification.
Verification uses the Web Crypto API, which supports RSASSA-PKCS1-v1_5 and ECDSA. For RSA the signature is checked directly; for ECDSA the DER-encoded r/s signature is converted to the raw IEEE P1363 form and verified against the named curve (P-256 / P-384 / P-521). Algorithms the browser cannot verify — RSASSA-PSS (which needs explicit parameters), Ed25519, Ed448, DSA and any SHA-224 variant — are still fully decoded, but the badge honestly reports them as unsupported rather than guessing.
Detailed Explanation
📖How It Works
What the CSR Decoder Does
The CSR Decoder parses a PKCS#10 Certificate Signing Request (RFC 2986) entirely in the browser and presents its contents in readable form: the Subject distinguished name, the subject public key (algorithm and size or curve), the signature algorithm, and the requested attributes and extensions — Subject Alternative Names, key usage, extended key usage, basic constraints and any challenge password. It also verifies the CSR’s own self-signature and computes a SHA-256 fingerprint. Because it is client-side, the CSR text is never transmitted — useful when a request reveals internal hostnames, org units or contact addresses.
Input: PEM CSR (-----BEGIN CERTIFICATE REQUEST-----) or bare Base64 DER
Output: Subject DN, public key, signature algorithm, requested SANs / usage / constraints
Verifies the self-signature and shows a SHA-256 fingerprint of the DER
Implements PKCS#10 / RFC 2986 and reuses the ITU-T X.690 (DER) engine
Runs fully in-browser; the CSR is never uploaded and the private key is never needed
⚙️Methodology
How the Parser Reads a CSR
A hand-written DER reader (shared x509Engine.ts, extended by csrEngine.ts) walks the request as a tree of ASN.1 Tag-Length-Value nodes and maps it onto the PKCS#10 CertificationRequest: certificationRequestInfo (version, subject Name, subjectPKInfo, and the [0] attributes), the signatureAlgorithm, and the signature BIT STRING. The Subject is decoded from its RDNSequence; the public key yields the RSA modulus bit-length and exponent or the EC named curve. The attributes SET is scanned for the extensionRequest attribute (OID 1.2.840.113549.1.9.14), whose value is a SEQUENCE OF Extension identical in shape to X.509 v3 extensions, so SANs, key usage, extended key usage and basic constraints are decoded with the same helpers.
Subject decoded from RDNSequence; SANs decoded from the GeneralNames CHOICE
extensionRequest (PKCS#9) carries the requested X.509 v3 extensions
Public key: RSA modulus bit-length + exponent, or the EC named curve
No ASN.1 library dependency — the parser is written from scratch
🔧Technical Details
Self-Signature Verification via the Web Crypto API
A PKCS#10 request is self-signed: the signature is computed over the DER of certificationRequestInfo using the private key that matches the enclosed public key. This tool imports that public key with crypto.subtle.importKey (SPKI format) and verifies the signature with crypto.subtle.verify. RSA PKCS#1 v1.5 signatures (SHA-1/256/384/512) are checked directly; for ECDSA the DER-encoded r/s value is first converted to the raw IEEE P1363 form and verified against the named curve (P-256 / P-384 / P-521). A valid result proves the applicant holds the matching private key — it is not a trust decision. Algorithms the browser cannot verify are decoded and reported honestly as unsupported.
Signature is over certificationRequestInfo, verified with the enclosed public key
RSASSA-PKCS1-v1_5 checked directly; ECDSA r/s converted from DER to P1363
Supported: RSA PKCS#1 v1.5 and ECDSA on P-256 / P-384 / P-521
Unsupported (decoded, not verified): RSASSA-PSS, Ed25519, DSA, SHA-224
A valid self-signature proves key possession, not trust or issuance
⚠️Limitations
Honest Limitations: A CSR Is a Request, Not a Grant
A CSR only proves possession of the private key and states what the applicant is requesting. A valid self-signature here does not establish trust and does not guarantee issuance: the certificate authority runs its own validation and policy, and may add, drop or override fields, so the issued certificate can differ from the request. This tool reads and self-signature-checks a CSR; it does not submit it, does not contact a CA, and cannot say whether a certificate will be granted. The private key never appears in a CSR and is never needed — users should not paste one. Uncommon or malformed structures may be visible only in the raw ASN.1 tree.
Proves key possession + states a request; does NOT grant trust or guarantee issuance
The CA decides the final certificate and may change requested fields
Does not submit the CSR or contact any certificate authority
The private key is never part of a CSR and is never required here
Exotic or malformed fields may appear only in the raw ASN.1 tree
🔒Privacy & Security
Private by Design
Everything happens on your device. The PEM is base64-decoded and parsed by a local ASN.1 engine, and the self-signature and fingerprint are computed with the Web Crypto API, so the CSR text never touches a server, database, CDN or log. This matters because a CSR can disclose internal hostnames, organisational units and email addresses. Nothing is persisted, the tool works offline once cached, and closing the tab erases everything; the only optional network use anywhere on the site is consent-gated ads that never see your CSR.
No upload, server, database, CDN or telemetry in the processing path
CSR subject, key and requested details never leave your device
Nothing persisted; works offline once cached
Your private key is never involved
Only optional network use is consent-gated ads that never see your CSR
What a CSR decode does vs what a CA does
Capability
This decoder
The certificate authority
Read Subject DN / public key / requested SANs
Yes — locally
Yes
Verify the CSR self-signature (key possession)
Yes — Web Crypto
Yes
Compute a SHA-256 fingerprint of the DER
Yes
Yes
Validate domain / organisation ownership
No
Yes
Decide which fields end up in the certificate
No
Yes
Issue the certificate
No
Yes
Send the CSR to a server
Never
You submit it to them
This tool decodes and self-signature-checks a CSR entirely in the browser; it does not submit it or issue anything. The CA controls validation and issuance. As of July 2026.
