Digital Signature Generator: The Complete Guide to RSA Signing and Verification

A digital signature is the cryptographic equivalent of a tamper-evident wax seal on a document. It proves three things at once: who signed the data, what data they signed, and that the data has not been altered since the signature was applied. Unlike a handwritten signature, which looks the same on every document, a digital signature is unique to both the signer's private key and the exact bytes of the message being signed.

Digital signatures underpin much of the trust infrastructure of the modern internet. Every TLS certificate, software update, blockchain transaction, and authenticated API call relies on some form of signature verification. They make it possible to establish authenticity and integrity over channels where you can never physically meet the other party.

The Digital Signature Generator at Online Tools Forge lets you perform all three core operations — key pair generation, message signing, and signature verification — entirely in your browser. Built on the native Web Crypto API, it never sends your keys or messages to any server. This guide walks through what digital signatures are, how the tool works, and how to use RSA signatures correctly in your own projects.

Why Use a Digital Signature Generator?

A purpose-built signature generator removes the friction of working with public-key cryptography:

• Generate keys instantly. Create fresh RSA-2048, RSA-3072, or RSA-4096 key pairs with a single click — no OpenSSL boilerplate, no command-line flags to misremember.
• Sign without leaving the browser. Messages up to 1 MB are signed locally using the same Web Crypto primitives that power TLS and WebAuthn. Your data never touches a network.
• Verify signatures with confidence. Paste a public key, a message, and a signature to check whether they match. The tool reports success or failure in real time, making it ideal for debugging signing flows.
• Export in the format you need. Download keys as PEM, JWK, or raw Base64 — whatever your stack expects.
• Compare algorithms side by side. Switch between RSASSA-PKCS1-v1_5 and RSA-PSS, across SHA-256/384/512, to see how the choice affects output and behavior.
• No setup, no keys to manage. Everything runs client-side. There is no account, no API token, and nothing persisted after you close the tab.

Key Features

The tool is organized into three tabs — Generate Keys, Sign, and Verify — each backed by the window.crypto.subtle Web Crypto API.

Supported Algorithms

RSA-PSS uses a random salt on each signature, so signing the same message twice produces two different (but both valid) signatures. This defeats certain replay and chosen-message attacks that PKCS1-v1_5 is theoretically vulnerable to.

Hash Functions

RSA Key Sizes

All keys are generated with a public exponent of 65537 (0x010001), the de facto standard value that provides both efficiency and security.

Output Formats

Operational Constraints

• Max message size: 1 MB (1,048,576 bytes)
• Public exponent: 65537 (fixed)
• Execution: 100% client-side via window.crypto.subtle

How to Use the Digital Signature Generator

1. Generate a Key Pair

1. Open the Digital Signature Generator and select the Generate Keys tab.
2. Choose a key size — 2048 is the sensible default; use 3072 or 4096 for higher security or longer-lived keys.
3. Choose an algorithm (RSASSA-PKCS1-v1_5 or RSA-PSS) and a hash function (SHA-256 is the default).
4. Click Generate. The browser derives a fresh key pair in a few hundred milliseconds.
5. The public and private keys appear in your chosen output format (PEM, JWK, or Base64).
6. Use Copy to grab either key, or Download to save it to disk.

Keep the private key secret and store it somewhere safe — anyone who obtains it can sign on your behalf.

2. Sign a Message

1. Switch to the Sign tab.
2. Paste your private key (in the same format and algorithm you generated it with).
3. Enter the message you want to sign (text up to 1 MB).
4. Confirm the algorithm and hash match the key.
5. Click Sign. The tool returns a Base64-encoded signature.
6. Copy or download the signature. Distribute it alongside the message to recipients.

3. Verify a Signature

1. Switch to the Verify tab.
2. Paste the public key that corresponds to the signing private key.
3. Paste the original message.
4. Paste the signature produced in the previous step.
5. Click Verify. The tool reports whether the signature is valid or invalid in real time.

A failed verification means either the message was modified, the signature is wrong, or the public key does not match the private key used to sign.

Understanding the Concepts

RSA and Public-Key Cryptography

RSA is an asymmetric cryptosystem: it uses a mathematically linked key pair — a public key that can be freely shared, and a private key that must stay secret. In RSA, security rests on the difficulty of factoring the product of two large prime numbers.

The same key pair can be used for two distinct operations:

Digital signatures use the signing direction: the private key holder produces the signature, and anyone with the public key can validate it.

Public vs Private Keys

• Private key — the secret half of the pair. Used to create signatures and to decrypt messages. Never share it, never commit it to source control, never transmit it unencrypted.
• Public key — the open half. Safe to distribute widely. Used to verify signatures and to encrypt messages intended for the key pair's owner.

Because verification only needs the public key, signatures scale: one signer can produce a signature that millions of people independently verify without ever learning the signer's secret.

Hashing in Signatures

RSA signatures are not applied directly to the message. Instead, the message is first passed through a cryptographic hash function (SHA-256, SHA-384, or SHA-512), producing a fixed-size digest. The private key then signs that digest.

This matters for two reasons:

1. Performance. Signing a 256-bit hash is far faster than signing a megabyte document.
2. Security. Hashing binds the signature to the exact content of the message. Changing a single bit of the original message produces a completely different digest, and therefore an invalid signature.

Signing vs Encryption

It is easy to conflate signing with encryption, since both use key pairs — but they serve opposite goals:

• Encryption protects secrecy. You encrypt to someone using their public key.
• Signing protects authenticity. You sign as someone using your private key.

You can combine both: sign a message with your private key, then encrypt the message-plus-signature with the recipient's public key. The recipient decrypts with their private key and verifies the signature with your public key — achieving confidentiality, integrity, and authenticity in one exchange.

Code Examples

Signing with the Web Crypto API

async function rsaSign(message, privateKeyJwk, hash = 'SHA-256') {
  // Import the private key from JWK
  const privateKey = await crypto.subtle.importKey(
    'jwk',
    privateKeyJwk,
    { name: 'RSASSA-PKCS1-v1_5', hash },
    false,
    ['sign']
  );

  // Encode the message
  const data = new TextEncoder().encode(message);

  // Sign it
  const signature = await crypto.subtle.sign('RSASSA-PKCS1-v1_5', privateKey, data);

  // Return as Base64
  return btoa(String.fromCharCode(...new Uint8Array(signature)));
}

Verifying a Signature

async function rsaVerify(message, signatureBase64, publicKeyJwk, hash = 'SHA-256') {
  const publicKey = await crypto.subtle.importKey(
    'jwk',
    publicKeyJwk,
    { name: 'RSASSA-PKCS1-v1_5', hash },
    false,
    ['verify']
  );

  const data = new TextEncoder().encode(message);
  const signature = Uint8Array.from(atob(signatureBase64), (c) => c.charCodeAt(0));

  const valid = await crypto.subtle.verify('RSASSA-PKCS1-v1_5', publicKey, signature, data);

  return valid; // true or false
}

Generating a Key Pair

async function generateKeyPair(bits = 2048, algorithm = 'RSASSA-PKCS1-v1_5') {
  const keyPair = await crypto.subtle.generateKey(
    {
      name: algorithm,
      modulusLength: bits,
      publicExponent: new Uint8Array([1, 0, 1]), // 65537
      hash: 'SHA-256',
    },
    true,
    ['sign', 'verify']
  );

  // Export to JWK for storage
  const publicJwk = await crypto.subtle.exportKey('jwk', keyPair.publicKey);
  const privateJwk = await crypto.subtle.exportKey('jwk', keyPair.privateKey);

  return { publicJwk, privateJwk };
}

RSA-PSS with a Salt

For RSA-PSS, pass the salt length explicitly — 32 matches a SHA-256 digest:

const signature = await crypto.subtle.sign({ name: 'RSA-PSS', saltLength: 32 }, privateKey, data);

const valid = await crypto.subtle.verify(
  { name: 'RSA-PSS', saltLength: 32 },
  publicKey,
  signature,
  data
);

Real-World Use Cases

Document Signing

Contracts, invoices, and legal agreements increasingly carry digital signatures. By signing the document's hash with an RSA key, you produce a non-repudiable record: the signer cannot later deny having signed that exact version of the document. PDF, PAdES, and similar standards build on exactly this mechanism.

API and Webhook Security

Services like Stripe, GitHub, and Slack sign their webhook payloads so you can verify a request genuinely came from them. The flow is the same one this tool demonstrates: the provider signs the payload with a private key, you verify it with their published public key, and a mismatch means the request should be rejected.

Software Distribution

Every macOS app, every signed Windows executable, every Linux package, and every Docker image (via cosign) carries a signature tied to the publisher's key. Before installing, your system verifies the signature against a trusted root — if the bytes were modified or the key is unknown, installation is blocked.

Blockchain and Cryptocurrency

Transactions on networks like Ethereum and Solana are signed with a private key (typically ECDSA or EdDSA, the elliptic-curve cousins of RSA). The network verifies each signature with the sender's public key before accepting the transaction, ensuring only the key holder can move the funds.

Digital Certificates and TLS

When your browser connects to https://onlinetoolsforge.com, the site presents an X.509 certificate whose contents are signed by a Certificate Authority's private key. Your browser verifies that signature using the CA's public key (built into the OS or browser trust store). This is how you know you are talking to the real site and not an impostor.

Best Practices

Key Size

• 2048 bits is the current minimum for general-purpose use and remains the default for most TLS certificates.
• 3072 bits is a strong choice for new systems that want a comfortable margin without paying for 4096's performance cost.
• 4096 bits is appropriate for long-lived root keys or compliance-driven environments, but signing and verification are noticeably slower.
• Never go below 2048. Keys of 1024 bits are considered broken and should be retired immediately.

Key Storage and Rotation

• Treat private keys like passwords: encrypt them at rest, restrict file permissions, and never hard-code them in source.
• Rotate keys periodically — every 1–2 years for most applications, sooner if you suspect compromise.
• Keep a revocation path so a compromised key can be invalidated before its natural expiry.
• Use a key management service (AWS KMS, Google Cloud KMS, HashiCorp Vault) for production keys rather than storing them on disk.

Algorithm Selection: PSS vs PKCS1

When in doubt, default to RSASSA-PKCS1-v1_5 with SHA-256 for maximum interoperability, and choose RSA-PSS when you control both ends of the conversation and want the strongest available security guarantees.

Hash Selection

• Use SHA-256 unless you have a specific reason to go higher. It is fast, widely supported, and matches the RS256/PS256 conventions.
• Use SHA-384 or SHA-512 when a standard or policy mandates it, or when you want a larger security margin on long-lived keys.
• Avoid SHA-1 and MD5 — both are cryptographically broken and must not be used for signatures.

Operational Hygiene

• Always sign the exact bytes you intend to verify. Different line endings, trailing whitespace, or character encodings will produce different hashes and break verification.
• When signing structured data, canonicalize it first (e.g., JSON Canonical Form) so that semantically identical inputs produce identical bytes.
• Include a timestamp or nonce in signed payloads to prevent replay attacks.
• Log verification failures — they are often the first sign of a tampering attempt.

Start Signing Today

The Digital Signature Generator gives you a complete, browser-based toolkit for RSA key generation, signing, and verification — no installations, no servers, and no data leaving your machine. Whether you are debugging a webhook signature, testing a JWT signing flow, or learning how public-key cryptography works, it handles the crypto primitives so you can focus on your application.

Try the Digital Signature Generator now →

Related Tools

• HMAC Generator — symmetric (shared-secret) message authentication when you don't need public/private keys.
• JWT Generator — create and inspect JSON Web Tokens, including RS256-signed tokens built on RSA.
• Password Generator — generate strong, random passwords to protect access to your key material.
• UUID Generator — create unique identifiers for correlating signed messages and audit logs.