You draw your signature with a mouse, drop it on the last page, and download the file. It looks signed. But nothing about that image stops someone from opening the PDF afterward, changing a number on page two, and re-saving it — your signature-shaped picture sits there looking just as convincing on the tampered version as it did on the original. If you need the file itself to prove it wasn’t touched after you signed it, a picture of a signature can’t do that. A real digital signature can.

Two different things that both get called “signing”

“Sign this PDF” usually means one of two very different operations, and it’s worth being precise about which one you need:

A drawn or typed signature is a visual stamp — a picture that goes on top of the page. It’s what tools like Fill & Sign do, and it’s genuinely the right tool for most everyday signing: approving an internal memo, initialing a form, agreeing to informal terms. It’s fast, it looks like a signature, and for documents where nobody’s disputing authenticity, that’s enough.

A digital signature is cryptographic. Signing embeds a PKCS#7 signature block into the PDF’s actual structure — the same standard Adobe Acrobat and every compliant PDF reader use — built from a certificate and a private key. The signature is mathematically tied to every byte of the document at the moment you sign. Change so much as one character afterward — a date, a clause, a figure — and the signature no longer validates. Any PDF reader that checks signatures will show the file as altered.

The two aren’t competing for the same job. One creates something that looks signed. The other creates something a computer can verify is unaltered since signing.

How a reader actually checks it, not just “trust me”

When a PDF reader says a signature is “valid,” it isn’t taking your word for it — it’s redoing the math. It recalculates a cryptographic hash of the exact bytes that were signed and compares that against the hash embedded inside the signature block. Change one byte after signing and the hashes stop matching, so the reader flags the document as altered. Separately, it uses the public key inside the certificate to confirm that hash really was signed by whoever holds the matching private key — that’s the “who signed it” half.

Those are two different questions, answered by two different checks. “Has this file changed since signing?” always gets a definitive yes-or-no from the math, regardless of whose certificate was used. “Do I trust the name on the certificate?” depends on whether that certificate chains back to an authority the reader’s software already trusts — which is exactly the self-signed-vs-CA distinction covered below. A reader can correctly say “unaltered, but I don’t recognize the signer” in the same breath — that’s not a bug, it’s two separate guarantees being reported honestly instead of collapsed into one.

Who actually needs the cryptographic version

Most signing doesn’t need this. But some situations specifically call for it:

  • Freelancers and consultants sending contracts — a client can’t quietly renegotiate a clause after you’ve both “signed” and claim it was always that way, because the signature would break.
  • Anyone who needs to prove a document wasn’t altered after signing — audit reports, technical sign-offs, deliverable approvals, anything where “this is exactly what I agreed to” matters more than “this has my name on it.”
  • People who already hold a certificate and don’t want to buy software to use it — if you have an Indian DSC (Digital Signature Certificate) used for GST filings, income tax returns, or tender submissions, you already own something recognized as a trusted signing identity. You shouldn’t need a paid desktop tool just to apply it to a PDF.

If none of that describes your document, a drawn signature is simpler and entirely fine. This tool is for when the file needs to prove something, not just look complete.

Is a digital signature legally binding?

Yes, generally — but it’s worth knowing what the law actually credits it for, because it isn’t quite what people assume.

In the US, the ESIGN Act and UETA make an electronic signature enforceable once it shows the signer’s intent and the record stays intact — a plain drawn signature already clears that bar for most everyday contracts. A cryptographic signature doesn’t grant an ordinary agreement more legal validity than that. What it adds is evidence: proof, built into the file itself, that nobody edited the document after signing. That’s a stronger position if a dispute ever comes down to “which version did we actually agree to,” not a different legal category.

The EU’s eIDAS regulation is more explicit about tiers. A “simple” electronic signature is any electronic mark. An “advanced” electronic signature has to be uniquely linked to the signer and detect any later change — roughly what a self-signed certificate gives you here. A “qualified” electronic signature is an advanced one where the certificate comes from a specifically EU-accredited trust provider, and it’s the only tier eIDAS says carries the same legal weight as a handwritten signature automatically, no argument needed.

India has its own framework under the IT Act, 2000, and it’s directly relevant to the DSC path above: a Digital Signature Certificate issued by a licensed Certifying Authority — the kind used for GST, income tax, and e-tender filings — has a specific legal status the Act names outright, distinct from the broader “electronic signature” category the Act also recognizes (Aadhaar eSign, for instance). Uploading your existing DSC through Digitally Sign PDF isn’t just adding cryptography — it’s applying a signature type Indian law already has a name for.

None of this is legal advice for your specific document. If real money or liability is riding on it, check what your contract or your regulator actually requires before assuming any signature type — cryptographic or not — automatically clears the bar.

The two signing paths on Digitally Sign PDF

The tool offers two ways to get a signing identity, and picking the right one matters:

Create a free signature on the spot. Enter your name (and optionally email and organization), and the tool generates a fresh RSA-2048 keypair and a self-signed certificate right there in your browser — no account, no waiting. This proves the document hasn’t been altered since signing and that it was signed by whoever held that private key. What it can’t do is prove who that actually is — since no certificate authority is vouching for the identity, PDF readers will show the signature as “unverified” or “unknown” until the person reading it explicitly chooses to trust your certificate.

Use a certificate you already own. If you have a .pfx or .p12 file — a DSC, or any certificate issued by a recognized certificate authority — upload it and enter its password. The tool reads out the private key and certificate and signs with those instead. Because a trusted authority already vouches for that certificate, PDF readers that trust the same authority will show the signature as verified automatically, with no extra step from the person opening the file.

Both paths produce a genuinely valid cryptographic signature. The difference is entirely about identity: whether the reader’s PDF viewer already has a reason to trust the name attached to it.

What “self-signed” actually means for the person receiving the file

This is the part people most often get wrong in either direction — assuming a self-signed signature is worthless, or assuming it’s equivalent to a CA-issued one.

A self-signed certificate is completely real cryptography. The math is identical to what a paid certificate authority uses. If your recipient opens the signed PDF and nobody has touched it since you signed, the signature validates and the reader confirms the content is intact. That part works regardless of who issued the certificate.

What’s missing is a trusted third party confirming that “the person named on this certificate is actually who they say they are.” A certificate authority does identity verification before issuing a certificate — that’s what a CA-issued or DSC signature buys you: the reader’s software already trusts that authority, so the signer’s identity shows as verified with no manual step. A self-signed certificate skips that verification, so the reader sees “signature valid, but the signer’s identity is unverified” — which is a meaningfully different, weaker claim than a CA-backed signature, even though the tamper-detection is identical.

For a lot of real use — an internal deliverable sign-off, a document you’re sending to someone who already knows you, a personal record you want proof-of-integrity on — that’s completely fine, since the recipient already knows who you are; the certificate is just proving the file itself hasn’t moved. For anything where a stranger or a formal process needs to trust your identity from the certificate alone — many contracts, tax and regulatory filings, tenders — you want the CA-issued path, which is exactly why uploading your own DSC is supported directly.

If you generate a self-signed certificate and expect to reuse the same identity for future documents (so all your signatures trace back to one consistent certificate instead of a new throwaway one each time), you can save it as a password-protected .p12 file right after generating it and reuse that file on your next document.

What else the signature carries

Two optional fields — reason and location — get embedded in the signature itself, alongside your name, email, and the signing timestamp. “Reviewed and approved” or “Countersigned per contract §4” as a reason, or a city as location, show up when someone inspects the signature’s details in their PDF reader. A visible stamp also gets placed in the corner of the last page so anyone opening the file can see at a glance that it’s signed — but that stamp is just a courtesy; the actual proof is the embedded cryptographic signature underneath it, which is what a reader checks when it says “valid” or “invalid,” not the picture in the corner.

Nothing leaves your browser

Whichever path you choose, the certificate, its password, and the private key are processed entirely on your device — generating a fresh certificate, unlocking a .pfx/.p12, and building the actual PKCS#7 signature all happen in-browser. Nothing about your identity or your signing key is ever uploaded anywhere, which matters especially if you’re signing with a DSC you also use for official tax or tender filings.

Where this actually gets used

  • Freelance and consulting contracts — sending a proposal or agreement where both sides need confidence nothing gets edited post-signature.
  • Filings with an existing DSC — applying a certificate you already hold for GST, income tax, or e-tender submissions to a PDF without installing signing software.
  • Deliverable and audit sign-off — cryptographically marking a report or dataset as final, so any later edit is detectable.
  • Anything currently “signed” with a scanned signature image — upgrading from a picture that proves nothing to a signature that proves the document is exactly what was agreed.

If you just need to drop your signature onto a form and move on, Fill & Sign is still the faster tool for that. Reach for Digitally Sign PDF when the document needs to prove, not just show, that it hasn’t been changed.