Sign PDF Online

How It Works

1. Upload your PDF file using the drop zone above.
2. Draw your signature on the canvas or type your name in a cursive font style.
3. Adjust the signature color and size to your preference.
4. Navigate through PDF pages and click exactly where you want to place your signature.
5. Add signatures to multiple pages if needed.
6. Click "Download Signed PDF" to save your signed document.

Why Use a Digital Signature?

Digital signatures are perfect for signing contracts, agreements, forms, and documents without printing or scanning. They're secure, legally recognized in most jurisdictions, and much more convenient than handwritten signatures. Use this tool to quickly add your personal signature to any PDF document.

Signature Options

• Draw · Use your mouse, touchpad, or stylus to draw your handwritten signature on the canvas.
• Type · Type your name and choose from various cursive and script fonts for a personalized signature style.
• Color · Pick any color for your signature; black is standard for formal documents.
• Size · Adjust the signature size (50-200%) to fit perfectly on your PDF pages.
• Placement · Click anywhere on the PDF page to place your signature at the exact location you need.
• Multiple Pages · Add signatures to any page in your PDF document by navigating and clicking.

Frequently Asked Questions

Is my PDF secure and private?

Yes. All processing happens in your browser. Your PDF and signature never leave your device and are not uploaded to any server or stored anywhere.

Can I sign multiple pages?

Yes. Use the page navigation buttons to move between pages. Create your signature once, then click on each page where you want to place it.

Can I undo a signature placement?

To remove a signature, clear the PDF and re-upload it. Once you download, you can always re-sign with different placements.

What "signing a PDF" actually means in 2026

The phrase "signing a PDF" covers four genuinely different operations that the PDF specification and the law treat distinctly, although end users almost never distinguish them. The simplest, and what this tool produces, is an image-overlay signature: the user draws or types a name, the result is rasterised to a transparent PNG, and pdf-lib places the image as a visible decoration on the chosen page. The output PDF has a picture of a signature on it. There is no cryptography, no key, no certificate, no audit trail. Every PDF reader on every platform displays the signature identically because it is just an image in the page content stream.

The second form is a typed-name-as-text signature combined with a checkbox or click-to-sign. Functionally similar to the image case but the signature is a text object rather than a raster. Same legal status. The third form is a digital signature in the PDF specification's sense: a /Sig field with a SubFilter such as /adbe.pkcs7.detached, a ByteRange describing the signed portion of the document, and a CMS (PKCS#7) envelope holding the signature itself. The signature is computed over a hash of the document bytes and is verifiable using the signer's X.509 certificate. PDF readers display a "signed by" panel reporting the signer's identity, signature validity (matches the bytes), and certificate trust (chains to a trust anchor).

The fourth form is a PAdES signature, a digital signature conforming to the ETSI EN 319 142 profiles: B-B (baseline), B-T (with a TSA timestamp), B-LT (with embedded revocation information), or B-LTA (with archival timestamping that keeps the signature verifiable for decades). PAdES is what satisfies the eIDAS Qualified Electronic Signature (QES) requirement in the European Union, which gives the signature the same legal weight as a handwritten signature across the EU. This tool produces the first form. It is right for informal contracts, internal documents, agreements, school paperwork, and the large set of "I just need to sign this and send it back" situations. It is not appropriate for documents that legally require QES, for cross-border commercial contracts with formal signature requirements, or for documents that must remain cryptographically verifiable years later. For those, a PAdES-capable application with a qualified certificate is needed.

Why image-overlay signatures still hold up in most situations

It surprises some users that a drawn or typed signature is legally valid for most everyday purposes. The pertinent US law is the E-SIGN Act (2000) at the federal level and the Uniform Electronic Transactions Act adopted by 49 of 50 states. The doctrinal anchor goes further back: Restatement (Second) of Contracts Section 134 defines a signature as "any symbol made or adopted with an intention, actual or apparent, to authenticate the writing as that of the signer." A drawn signature, a typed name, an "X" mark, even a tick in a checkbox can satisfy this definition provided the surrounding context shows authenticating intent.

In the European Union the picture is more layered. eIDAS defines three levels: Simple Electronic Signature (SES) is any electronic mark indicating intent (drawn, typed, ticked). Advanced Electronic Signature (AdES) requires the signature to be uniquely linked to the signer, identify them, be under their sole control, and detect any later changes to the document. Qualified Electronic Signature (QES) is an AdES backed by a qualified certificate from an eIDAS-licensed Trust Service Provider produced with a Qualified Signature Creation Device. SES is what this tool produces; QES requires a smart card or USB token and a PAdES-aware application. SES is admissible in court for most documents. Where the law specifically demands AdES or QES (real estate transactions in some jurisdictions, tax filings in others, employment contracts in a few, and any document the parties have contractually agreed will be QES-signed), this tool is not the right one and using it would not satisfy the legal requirement. Outside those specific categories, an image-overlay signature with a clear paper trail (email receipt of the file, timestamp on the email, audit log of the upload, version of the document at signing) is generally defensible.

How this tool builds the signed PDF

This tool runs entirely in the browser using two open-source JavaScript libraries: Mozilla's pdf.js to render the document for visual placement and pdf-lib to write the signature into the output. When you upload a PDF, the bytes are read into an ArrayBuffer in browser memory and never leave the page. pdf-lib parses the document; pdf.js (running in its dedicated web worker, which keeps PDF parsing off the main thread) renders each page to a canvas as you navigate. The signature is captured separately on a 600x180 pixel canvas: pointer events (mouse, touch, stylus) are translated into line segments along the canvas's 2D drawing context. When you click on the rendered PDF page to place the signature, the click coordinates are translated from the visible canvas resolution into the page's PDF user-space coordinate system, taking the current zoom and page dimensions into account.

The final write-out is the pdf-lib step. The signature canvas is exported as a PNG data URL, decoded into a Uint8Array, and embedded into the output PDF via pdf-lib's embedPng() and drawImage() APIs. pdf-lib's save() pipeline rewrites the document with the embedded image stream and the page content stream extended to reference it. The result is a standard, valid PDF with the signature image embedded as a normal image object on the page; any PDF reader displays it identically. The output is not byte-identical to the input. The cross-reference table is rewritten, object numbering may shift, streams may be re-encoded with different filter choices, and pdf-lib applies its own compression defaults. The visible content is unchanged except for the added signature. If the input PDF contained a digital signature (a /Sig field), that signature will be reported as invalid in the output because the document bytes have changed; signed PDFs should be re-signed with a digital-signature tool after rewriting.

Drawing on a canvas, the technical detail

Browsers have provided unified pointer events for mouse, touch, and stylus input since the Pointer Events Level 3 specification reached W3C Recommendation in 2024. Safari and some mobile browsers still rely on the legacy Touch Events spec. A robust signature canvas listens for both: mousedown/mousemove/mouseup for desktop pointing devices, and touchstart/touchmove/touchend with the { passive: false } option for mobile (the option is required so that preventDefault() can stop the page from scrolling under the finger while the user is signing).

Coordinates from pointer events are reported in the viewport, so they have to be translated into the canvas's local coordinate system. The standard approach is canvas.getBoundingClientRect() to get the canvas's position in the viewport, then subtract that from the event's clientX/clientY. The drawn signature is then rasterised to a PNG by canvas.toDataURL(), producing a base64-encoded data URL. This is the intermediate representation pdf-lib consumes via embedPng(). A common source of visible-image artefacts is alpha. The signature canvas starts with a transparent background (no fill); only the stroke pixels carry colour. When the canvas is converted to a PNG, non-stroke pixels are encoded as transparent and the signature appears overlaid on the underlying page when embedded. If the canvas had been initialised with a white fill, the signature would appear as a white box around the strokes when placed over a non-white page background.

Typed signatures and cursive fonts

The Type tab lets you enter your name and pick from four cursive-style web fonts: a generic cursive, Brush Script MT, Comic Sans MS, and Lucida Handwriting. None of these is guaranteed to be installed on every device, which is why each font choice falls back to the platform's generic cursive family. On macOS, Brush Script MT is widely available; on Windows, Lucida Handwriting is the typical fallback; on Linux without a desktop font stack installed, the cursive family resolves to whatever fontconfig chooses, often a default sans-serif. This is an intentional simplification. Embedding a custom cursive font in the page would mean shipping the font file with the tool (several megabytes per font, with licensing implications for many commercial cursive fonts) or fetching it from a font CDN (which would compromise the no-network-requests privacy guarantee).

The trade-off chosen here is that the typed signature uses whatever your device renders and is rasterised on your machine before being embedded into the PDF, so the embedded image looks the way you saw it in the preview. A user who needs a specific font for legal reasons (matching a corporate brand signature, for example) should draw rather than type, or prepare the signature in a desktop image editor and import it through a desktop PDF tool.

Real-world workflows that drive PDF signing

• Returning a signed contract by email. The most common case. A counterparty sends a PDF; you sign and email it back. This tool fits this workflow exactly: open the file, sign, download, attach to a reply. No round-trip through a SaaS portal, no account creation, no per-document fee.
• Internal documents and approvals. Expense reports, vacation requests, equipment-receipt acknowledgements, and similar forms. Image-overlay signatures are standard for these inside organisations because the internal audit trail (who sent the PDF, who returned it, the email metadata) provides the integrity guarantee.
• School and family paperwork. Permission slips, registration forms, medical authorisations, parental tax-related signatures. These are the highest-volume use case for personal e-signing and the one where the friction of creating a SaaS account is most disproportionate to the signature being requested.
• Independent contractor and freelance work. Statements of work, retainer agreements, NDAs, and invoice acknowledgements. Most freelance contracts are signed with an image-overlay signature and the contracts are enforceable; the audit trail is the email exchange.
• Real-estate document review. Pre-closing review of leases and purchase agreements. The closing signature for a real estate transaction often requires notarisation or a QES depending on jurisdiction, but the dozens of smaller documents around it (inspection reports, disclosures, appliance receipts) typically only need a casual signature.
• Annotating financial documents. Tax forms, insurance claim forms, bank-account opening documents. These often need a signature in a specific location for processing systems to accept them; placing the signature where a SaaS tool would put it by default is rarely the right spot.

Common pitfalls and what they mean

• Signature image is too small or too large in the downloaded PDF. The size slider operates in percentages of the canvas dimensions, not in PDF points. A 100% signature on a US Letter page (612 by 792 points) is sized differently than the same percentage on an A0 drawing (2384 by 3370 points). For unusual page sizes, place the signature, download, check the result, and adjust if needed.
• Signature appears upside down or in the wrong corner. The underlying cause is usually a PDF page with a /Rotate annotation that the rendering library has honoured but the writing library has not. pdf.js renders rotated pages with the rotation applied; pdf-lib places images in unrotated page coordinates. If your source PDF has rotated pages, normalise the rotation first with the PDF Rotate tool, then sign.
• Signature is visible in the preview but missing in the downloaded PDF. Two common causes. First, the preview was clicked before drawing on the canvas, so an empty placeholder was recorded. Second, the PNG data URL was corrupted in transit (rare in practice but possible if a browser extension is rewriting blob URLs). Refresh, draw, and place again.
• Drawing on a touchscreen lags behind the finger. Standard touch-events latency on most mobile browsers, not a bug in the canvas. Modern browsers coalesce multiple pointer events per frame, trading some smoothness for performance. A stylus typically produces better results than a finger because the pen tip generates more precise pointer events.
• Existing digital signature reports as invalid after signing. By design. If the input PDF has a /Sig field, any modification (signature, watermark, edit) invalidates the existing digital signature because the document bytes change. Either remove the existing digital signature first with a desktop tool, or accept that the digital signature on the output will be reported as invalid.
• Signed PDF will not open in a pre-2010 PDF reader. Rare but it happens occasionally with very old readers that do not handle modern PDF features pdf-lib emits by default. Workaround: open the signed PDF in a current reader, save it as PDF/A, and use the PDF/A version for the older reader.

Browser-only versus cloud signing

The cloud signing services that fill the top of search results (DocuSign, Adobe Sign, HelloSign/Dropbox Sign, PandaDoc, Smallpdf, ILovePDF, Sejda) all upload the PDF to their servers, render it server-side, capture the signature on a server-rendered canvas, and write the signed output server-side before serving it back as a download or storing it in their cloud. The privacy posture differs from a local-only signing tool in three ways. First, the document content transits the operator's network and is stored at least temporarily in operator logs and memory. Second, the operator now holds a copy of a signed document; some providers retain it indefinitely as part of the audit trail (Adobe Sign, DocuSign), others delete it after a defined window (Smallpdf within one hour, ILovePDF within two hours). "Deletion within X hours" is a commitment to delete from the primary store; backups, log archives, and analytics pipelines may have different retention.

Third, server-side signing services typically include a digital audit trail in the PDF metadata (IP address, timestamp, device information, recipient confirmation events). This audit trail is one of the main reasons users choose a cloud service: it provides legal defensibility. The trade-off is that the audit trail is created and held by a third party. This tool produces no audit trail, no embedded metadata about who signed, and no server-side record of the operation. The signature is just an image on the page. For situations where a cloud audit trail is needed (formal commercial contracts, regulated industries, documents likely to be contested), a cloud service is the right choice. For situations where a casual signature is sufficient and privacy is the priority, a local tool wins. The two are genuinely complementary; choose by the legal stakes of the document and the privacy of its content.

Long-term verification, when an image signature is not enough

An image-overlay signature remains visible indefinitely (the image is embedded in the document, and PDF is a long-lived format). What it does not have is cryptographic proof that the signature was applied at a specific time by a specific person and that the document has not changed since. PAdES B-LT and B-LTA profiles solve this by embedding a timestamp from a Time Stamping Authority (RFC 3161) and revocation information (CRL or OCSP responses, per RFC 5280) into the signature itself. The result is that, even if the signer's certificate is revoked, expired, or its issuing CA is no longer trusted, the signature can still be verified using the embedded information. B-LTA adds archival timestamping that periodically re-anchors the verification chain so the signature remains verifiable for decades, even as cryptographic primitives age.

For documents that need this kind of longevity (corporate archives, property deeds, court records, government records), an image-overlay signature is insufficient and a PAdES-compatible tool is required. Most desktop PDF tools (Adobe Acrobat Pro, Foxit PhantomPDF) and some open-source projects (PyHanko in Python, jSignPdf in Java) can produce PAdES signatures given access to a signing certificate. The certificate itself is typically issued by a national PKI (EU Trust Service Providers, US federal employees' Common Access Card, Estonia ID card, Singapore SingPass) or a commercial CA (DigiCert, Sectigo, GlobalSign). For routine documents, none of this is needed; for documents you expect to defend in court ten years from now, all of it is.

Practical: what makes a good e-signature

• Draw rather than type for documents where the visual character of the signature matters. A drawn signature looks like a signature. A typed name in Comic Sans looks like a typed name in Comic Sans.
• Keep the signature size reasonable. A signature that fills a third of the page looks like a child's drawing. A signature scaled to fit a typical signature line (around 200 by 60 points, roughly 100% of the default size here) looks correct.
• Sign in black or dark blue for formal documents. The blue convention dates from the historical distinction that ink signatures were written in blue while text was printed in black, making the signature visibly distinct from a photocopy.
• If the document has a "sign here" field, use its position as the placement target. The recipient's processing system may expect the signature in a specific location and reject it elsewhere.
• For multi-page documents, sign every page where requested rather than just the last page. Sign-each-page conventions exist precisely so that adding pages later cannot be done without forging the signature on the new page.
• Keep a record of the email that delivered the signed PDF. Sender, recipient, timestamp, message-ID. This is the cheap audit trail that gives an image-overlay signature its real-world defensibility.

More frequently asked questions

Is a drawn or typed signature legally valid?

In most jurisdictions, yes, for most everyday documents. In the US, the E-SIGN Act (2000) and UETA (adopted by 49 states) recognise electronic signatures as legally equivalent to handwritten ones in commerce. In the EU, a drawn or typed signature qualifies as a Simple Electronic Signature under eIDAS, admissible in court for most purposes. Where a document specifically requires an Advanced or Qualified Electronic Signature (some real estate, tax, and employment contexts), this tool is not sufficient and a PAdES-aware application with a qualified certificate is needed.

Does this tool produce a cryptographic digital signature?

No. This tool produces an image-overlay signature, which the PDF specification calls a visible signature appearance without the underlying /Sig field and CMS envelope. The output is a normal PDF with a picture of a signature on it; no reader will report it as cryptographically "signed by" anyone. For cryptographic digital signatures see Adobe Acrobat Pro, PyHanko, jSignPdf, or any PAdES-compatible tool with access to your signing certificate.

Can someone modify my signed PDF and pretend I signed the modified version?

In principle, yes. A drawn or typed signature embedded as an image is not cryptographically tied to the document bytes. Anyone with the output PDF can open it in an editor, change the text around the signature, and save it with the signature unchanged. The real-world defence is the document trail (email metadata, version history, witness, audit logs). If document-content integrity is the concern, use a cryptographic digital signature: the signature is mathematically bound to a hash of the document bytes, so any modification breaks it and is detectable.

Can I sign a PDF that is already digitally signed?

Yes, but the existing digital signature will be reported as invalid after this tool rewrites the document. Adding any content to a digitally signed PDF (signature, watermark, edit, even a comment) invalidates the signature because the document bytes change. If you need to preserve the existing signature, do not modify the document. Some PAdES workflows allow multiple signatures via incremental update without invalidating earlier signatures, but this requires a PAdES-aware tool; this browser tool always rewrites the document fully.

Is this audit-trail compliant?

No. This tool produces no audit trail. The signed PDF contains only the visible signature image; there is no embedded record of who signed, from what IP, at what time, with what authentication. For audit-trail-compliant signing (DocuSign-style audit certificate), use a cloud signing service. The trade-off is that audit-trail compliance requires the signing operation to happen on a trusted third-party server.

What about notarisation?

Notarisation is a separate operation from signing. A notary verifies the signer's identity and witnesses the signing; the notary's notarial certificate accompanies the document. This tool does not notarise. For documents that require notarisation (real estate deeds, certain affidavits, some powers of attorney), use a Remote Online Notarisation (RON) service authorised under RULONA in the US, or the equivalent in your jurisdiction.

Is there a desktop or programmatic alternative?

For image-overlay signing on the desktop, Adobe Acrobat Reader (free) supports "Fill & Sign" with a drawn or typed signature locally. For programmatic use, pdf-lib can be used as a Node.js library to script this same workflow; the same npm package powers many PDF processing pipelines. For cryptographic digital signatures, PyHanko (Python) and jSignPdf (Java) are the standard open-source choices, both with strong PAdES support including B-LTA.

Related Tools