A complete guide to decoding Certificate Signing Requests, what signature verification actually confirms, and how this fits with the other certificate tools on this site.
Launch the CSR Decoder →The CSR Decoder takes a PEM-encoded PKCS#10 Certificate Signing Request and parses it into a readable breakdown: subject fields, public key algorithm and size, signature verification status, and any Subject Alternative Names included in the extension-request attribute. It serves as the inspection counterpart to this site's CSR Generator, letting you check a CSR's exact contents before submitting it to a Certificate Authority, or verify a CSR you received from someone else before processing it.
Unlike the Certificate Decoder, which parses a finished, issued certificate, this tool specifically parses an unsigned request — and the page itself makes clear what information a CSR genuinely does and does not contain, since the two document types look superficially similar but serve very different purposes.
A finished X.509 certificate (the kind the Certificate Decoder tool parses) contains an issuer, a validity period, and a serial number, because all three of those are things a Certificate Authority adds when it signs and issues the certificate. A CSR, by contrast, is created before any of that happens — it's the request document submitted to a CA, not the final product — so none of those fields exist in it yet.
This tool's own on-page note states this directly: a CSR contains no issuer, validity dates, or serial number, since those are assigned by the Certificate Authority at the point of actual issuance, not by whoever is generating and submitting the request. Understanding this distinction matters specifically because it's easy to glance at a CSR and a certificate and assume they're interchangeable or that one is just an earlier version of the other with the same fields — they're genuinely different document types serving different stages of the certificate issuance process.
One of the key fields this tool reports is Signature Verification, which checks whether the CSR's own internal self-signature correctly matches the public key also contained within the request. This is a specific, narrow check, worth being precise about: a successful verification confirms that whoever created the CSR genuinely possesses the private key corresponding to the public key being submitted, and that the CSR's contents haven't been corrupted or tampered with since it was created.
A successful signature verification does not mean the subject information inside the CSR is truthful, that the requester actually owns the domain name being requested, or that a Certificate Authority will approve the request. Those are entirely separate verification steps that only the receiving CA performs, as part of its own identity and domain-ownership validation process. This tool's signature check is purely a technical integrity and key-possession check, mirroring the exact same check a real CA would perform as one of its first processing steps upon receiving any CSR.
If signature verification fails, it indicates either a genuinely corrupted or malformed CSR, or (for CSRs using an algorithm this tool's underlying library doesn't fully support for verification) a limitation in parsing rather than necessarily a problem with the CSR itself — the tool reports this honestly as "could not verify" rather than asserting a definitive failure when the underlying cause might simply be a parsing limitation.
Submitting a CSR to a Certificate Authority, especially a commercial one, often involves some amount of friction: forms to fill out, payment for certain certificate types, and a processing or validation delay before you find out whether the request was accepted. Discovering after that process that the CSR contained a typo in the Common Name, was missing a Subject Alternative Name you needed, or was generated with the wrong key algorithm for your intended use means repeating that entire process from scratch.
Decoding and reviewing a CSR's exact contents before submitting it — confirming the Common Name is spelled correctly, confirming all the domain names you need are present in the Subject Alternative Names list, and confirming the key algorithm and size meet whatever requirements your use case has — is a quick, free way to catch exactly these kinds of mistakes before they cost you a wasted submission cycle with a real CA.
NexTechTools offers four related but distinct certificate-and-key tools, and understanding how they relate helps clarify which one actually solves your current problem:
A typical real-world workflow using these tools together might look like: generate a CSR and private key using the CSR Generator, decode and double-check that CSR using this tool before submitting it anywhere, submit it to your chosen Certificate Authority, and once you receive the signed certificate back, use the Certificate Decoder to confirm it contains everything you expect before deploying it to your actual server.
-----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- markers.All CSR parsing happens entirely within your browser using the node-forge library loaded from a public CDN. No network request involving the CSR's actual content is ever made, and nothing you paste is transmitted anywhere, logged, or stored by NexTechTools.
Because a CSR by design does not contain your private key (only your public key), there's generally no significant sensitivity concern with sharing or pasting a CSR's content, though this tool applies the same no-logging, no-storage privacy standard as every other tool on this site regardless of the content's inherent sensitivity level.
CSRs don't have an expiration date, issuer, or serial number at all — those fields only get assigned once a Certificate Authority actually signs and issues a certificate based on the request. This is explained in detail in the Why a CSR Contains Less Information section above.
No. Signature verification only confirms the request's technical integrity and that you possess the matching private key. It says nothing about whether a Certificate Authority will approve your specific request, which depends on their own separate identity and domain-ownership verification process.
Yes. This tool parses any standard PEM-encoded PKCS#10 CSR, regardless of what software or tool originally generated it, as long as it follows the standard format.
Double-check that you pasted the complete CSR, including both the begin and end markers, with no missing or corrupted content. If the CSR was generated using an algorithm this tool's underlying library has limited support for verifying, the failure may reflect that parsing limitation rather than an actual problem with the CSR itself.