How to build a PDF signature tool with Bolt
Build a PDF signer where both your documents and your source code stay 100% local. Bolt executes the entire stack directly inside your browser tab: describe the viewer and signature canvas, test the live app in real time, and publish instantly without a backend.
Bolt
$ Build a single-screen PDF signer: open a document, draw a signature, drag it onto a page, then write it into the file and download it, all in the browser with nothing uploaded.
- Viewer running in the tab
- Placement maths corrected
- Ready for you to review
What a browser PDF signer actually is
A page that opens a document from your own disk, lets you draw your name and put it where it belongs, and writes it back into the file, with every one of those steps happening inside the browser tab rather than on a server somewhere.
The familiar version of this is a service. You upload the document, it lands on somebody else’s server, a link goes out, and a signed copy comes back. That works, and an enormous number of contracts go through it every day. It also means the document exists somewhere you do not control for as long as that company keeps it, which is unremarkable for a purchase order and is the entire conversation for anything covered by an agreement about where it may go.
The other version puts the machinery in the page. Mozilla’s pdf.js draws the document, and it is the same code built into Firefox rather than something exotic, so a browser displaying a contract is not the risky part. A canvas element captures a signature drawn with a mouse or a finger. Then pdf-lib writes that image back into the original file, which it can do because it runs in any JavaScript environment, browsers included. All three happen on the visitor’s own processor. Your server never sees the document, because there is no request that would hand it one.
What makes this harder than it sounds is a single conversion. The signature is dropped at a position measured in screen pixels, at whatever zoom the reader happens to be using. The finished PDF is written in points, seventy-two to the inch, measured from a corner at the other end of the page. Getting the mark to land where somebody put it is most of the real work here, and it is the part that looks finished long before it is.
The document is the whole trust story
Almost everything a cautious reader worries about here reduces to one question: does the file leave the device. Answer that with no and you have removed the account, the upload, the retention period and the breach notification at once, because none of them has anything left to sit on.
A signature is not the same as proof
Placing your name on a page is a signature in the ordinary legal sense. It is not an identity check, a timestamped record, or a seal showing the file is unchanged since. Those are separate things, they are what a paid platform actually sells, and working out which of them a given document needs is a decision rather than a feature.
The arithmetic is the product
A few hundred lines of interface, and one coordinate conversion. Get the conversion wrong and you ship a tool that puts the signature half an inch from where somebody dropped it, which is the one bug in this category nobody forgives, because they can see it.
Where the risk actually sits
48%
of breaches now involve a third party, and third-party involvement is up 60% year on year, from Verizon’s Data Breach Investigations Report, published May 2026 in its nineteenth annual edition.
verizon.com · checked August 2026
The parts every PDF signer is built from
Six parts, in roughly the order you would build them, and the fourth is where the difficulty lives. Each one is something you can describe to your AI coding tool in plain words and get back working.
Uploading & validating the PDF
Drag and drop, or a file picker, and then the unglamorous half: checking it really is a PDF, saying something clear when it is not, and deciding what happens to a file too large for a browser tab to hold comfortably. Half an hour of happy path, and an afternoon of everything else.
Rendering & navigating pages
Pages drawn at a size somebody can actually read, zoom that does not lose their place, and navigation for a document longer than one sheet. A signer that only works on a single page looks finished right up to the moment a real contract arrives.
Drawing your signature (touch & mouse)
A drawing surface that follows a mouse smoothly and a finger even more smoothly, an undo that goes back more than one stroke, and a way to start again. Touch is what decides this part: most people would rather sign with a finger than a trackpad, and a canvas built for a mouse feels wrong immediately on a phone.
Placing the mark exactly where you want
Dragging the signature onto the page, keeping it inside the page, knowing which page it landed on, and allowing more than one on a document. All of it is visible, which is why it is the part people demonstrate, and it is also where the coordinate conversion either works or quietly does not.
Embedding the mark & exporting PDF
Writing the signature into the original bytes and handing back something anybody can open, plus a way to get the untouched original back if the reader changes their mind. The output is the only thing that leaves, so it is the only thing worth testing in a reader you did not build.
Session persistence & memory limits
A refresh should not throw away the document and the signature somebody just spent five minutes on. A browser gives you somewhere small to keep both, and small is the operative word: the ceiling arrives sooner than anyone expects, and the failure is silent unless you go looking for it.
Own the tool or rent it by the document
Most people who sign a PDF this year will do it on somebody else’s platform, and for plenty of documents that is the right answer. What is worth looking at is the two things you are actually buying: a meter, and a body of evidence about who signed what.
Build your own
A signer you own is one build and a folder of files, with no account anywhere. Nothing counts your documents and nothing holds them, and with an AI coding tool writing it the build is a couple of weeks rather than a quarter.
- No count of documents, envelopes, transactions, or people allowed to sign
- The file is read off the disk and written back to it, so nothing is uploaded and nothing is retained by anybody
- Works with no network at all once the renderer is bundled with your build, which no hosted tool can offer
- Put your own name on it and give it to a client, a team, or a whole company at no extra cost
- Add typing, saved signatures, initials or a date stamp, because the code is yours to extend
- Full ownership: export it, run it on a machine inside your own network, keep it through the next procurement review
Rent an e-signature platform
DocuSign · Dropbox Sign · Adobe Acrobat Sign · iLovePDFA platform is working in five minutes and gives you the thing an owned signer genuinely cannot: a record. Who opened it, when, from where, and a seal that shows the file has not changed since. What you accept is an upload and a meter.
- The honest part first: signing your own document is free and unlimited on Dropbox Sign’s free plan, so for that one job there is nothing to build and nothing to pay
- Sending a document to somebody else is what gets counted, at 3 signature requests a month on that same free plan
- DocuSign Standard is $30 per user per month and allows up to 100 envelopes per user per year, with anything past that billed per envelope
- Adobe puts Individual and Small Business at 150 transactions per user per year, where a transaction is one document sent for signature
- A free web tool costs nothing and still uploads: iLovePDF keeps your file on its servers for up to two hours
- You get an audit trail and tamper evidence, which is the real product, and none of it comes with you if you leave
The default, and the one whose meter is easiest to hit without meaning to. Personal sends five envelopes a month. Standard and Business Pro carry "an Envelope allowance of up to 100 Envelopes per user per year", quoted from the pricing table, and excess envelopes are billed at a set per-envelope rate on top of the plan. Monthly plans are a separate ladder whose prices that page does not publish.
ecom.docusign.com · checked August 2026
In this list as a reality check rather than as a competitor. Its own help page says "The Free plan offers unlimited self-signing", so if all you ever do is sign your own documents, that costs nothing indefinitely. The free plan meters the other case at three signature requests a month. Essentials is $15/mo monthly or $10.05/mo billed yearly for one person, and Standard is $25 per user per month with a two-user minimum.
sign.dropbox.com · checked August 2026
Adobe’s own announcement, dated July 2026, states that "Adobe Sign Individual and Small Business plans include 150 transactions per user per year" and that "A transaction is a document sent from your account for signature". We quote no price for Adobe at all: its pricing pages would not load for us, twice, and a figure from a comparison blog is not a figure from Adobe.
community.adobe.com · checked August 2026
The free browser toolkit most people reach for, and the closest thing to what this build does. Its free tier is rationed per tool per day rather than overall, with a file-size cap alongside. The line that matters is not the price. Its own FAQ says "We just keep them for a maximum of 2 hours so you can download them", which is a fair policy, stated plainly, and is still your document on somebody else’s disk.
ilovepdf.com · checked August 2026
Split it by document rather than by product. Anything you sign yourself, and anything you would rather not hand to a company at all, belongs in a signer you own. Anything where you may later need to prove who signed and that nobody altered it afterwards belongs on a platform, and those are the documents worth paying for.
Why build with Bolt
There is no database here, no logins, and no permissions to get wrong, so most of the hidden work that stalls a solo build does not apply. What is left is one screen and one piece of arithmetic: a document drawn at a readable size, a canvas that follows a finger, and the conversion that turns where somebody dropped their signature into where it actually lands in the file.
Bolt runs the whole build in one tab, right down to the preview, and on this template that matters more than usual, because the thing being built also runs in a browser:
Prompt
Describe the screen or rule you want, in plain language.
Preview
Watch the running app rebuild itself in the same tab.
Try it
Click through the real app, because the preview is the actual build rather than a mockup.
Refine
Ask for the next change, or fix what’s off.
None of that needs an install or a terminal window, and the whole build happens in the tab GitHub just opened, one request at a time.
One conversionthat decides it
Screen pixels in, document points out, at any zoom and on any page size. It is the only genuinely hard thing here, and the preview is where you catch it, because a signature in the wrong place is obvious the moment you look at the file.
Auto-committed to GitHub as you go
Once GitHub is connected, Bolt commits each working change on its own and pulls in anything you changed elsewhere, so the two stay in sync without you typing a git command.
One tab and nothing installed
No terminal, no local setup, and no account anywhere else for this build, because there is no database to provision and no service to connect. The tab is the whole workshop.
Pay a developer, or do it with AI
Two ways to get the same tool. The figures on the left are what the work goes for. The figures on the right are what the tool costs to run once it exists, which on this build is the shortest column in our catalogue.
Hire a developer
Custom build, from scratch- Developer
- ~$5.8k-$23k
- Services to connect
- None
- Hosting
- $0 on a free tier
- Build time
- ~115 hrs of their work
~$5.8k-$23k to build, then close to nothing to run
That band is our ~115 hour estimate priced at what the work goes for. The rate survey cited below puts United States freelance web developers at roughly $40/hr while junior and $150/hr and up once senior, with agencies charging 20% to 40% above a freelancer for the same skills, so the floor here is about $50/hr and the ceiling about $200/hr for agency work. One thing to know before you brief anybody: the interface is the cheap half. The conversion between where a signature is dropped on screen and where it gets written into the file is where a fixed-price quote goes wrong.
Build it with Bolt
From scratch, with Bolt- Bolt
- Free (1M tokens/mo) to $25+/month (Pro, from 10M tokens)
- Hosting
- Free on Bolt’s own hosting, or Netlify
- Your time
- ~55 hrs
Free for a first look. A real build costs from ~$25/month on Pro once it outgrows the entry token rung, and climbs from there with usage
Bolt bills by tokens, and the sticker price understates what a real build costs: it reloads your whole project as context on every message, so the entry Pro rung (10 million tokens for $25/month) burns down faster than the number implies. Budget for a top-up or a higher rung on a multi-session build, not the $25 floor. Lean on Bolt’s own token-saving tools (clearing context between features, pointing a prompt at specific files) to slow that burn.
Either way the tool is yours and nothing about it is counted: not documents, not signatures, not the number of people who use it. This build also connects to no outside service at all, so there is no storage bill, no mail provider and no key to keep anywhere. The one exception is that adding an AI feature means paying a model provider for the text you send it, and only then.
Prices and rates from developex.com and bolt.new, checked August 2026.
Decide before you build
Six questions, none of them technical. The first two decide whether you should be building this at all, which is a better thing to find out now than in week two.
What you are signing, and what you must be able to prove
If a dispute is plausible, you need an audit trail and tamper evidence, and this build has neither. Sign your own paperwork here and route the contested, regulated, or notarised documents to a platform. Deciding per class of document beats deciding once for all of them.
Whether anybody else has to sign
One person signing their own document needs no server at all. Two people signing the same document needs an identity for each of them, a way to reach them, and somewhere the file can wait in between. That is a different application, and it is worth knowing which one you are building.
Drawn, typed, or an uploaded image
Drawing is what the template ships and what most people expect on a phone. Typing in a handwriting face is faster on a laptop and looks less like a real signature. An uploaded scan looks best and is the easiest to misuse. Pick one to start with and add the others later.
How large a document you will accept
A browser tab has a memory ceiling, and the place a refresh keeps your work has a much lower one, usually around five megabytes of text. Decide your limit, say it on screen, and check it in code, because an advisory number nothing enforces is not a limit, it is a hope.
Whether it has to work with no network
The renderer normally fetches one file from a public address as the page loads, which means a signer that fails on a plane, on a locked-down work laptop, and behind a strict security policy. Bundling that file with your build fixes it, and it belongs in the plan rather than in a later cleanup.
Who it is for, and whose name is on it
A tool for yourself needs almost no finishing. A tool you put in front of clients needs your branding, a page explaining the privacy claim in plain words, and enough error handling that nobody emails you about it. Same code, two quite different amounts of work.
Comparing your build options
Where you start decides how much of the time goes on the one hard part and how much on scaffolding around it. Here is the same tool three ways: from nothing, on a bought kit, or described to Bolt one piece at a time.
The interface goes up in a couple of days. What takes the rest of the time is the arithmetic nobody budgets for: turning a position on a screen into a position in a document, at every zoom level and on every page size, and then proving it landed there by opening the result in three different PDF readers rather than in your own preview.
A kit hands you a layout, a file dropzone and a button. It has never heard of a page, a point, or a signature that has to sit exactly where somebody put it, so the only part of this build anyone cares about starts from nothing, and you spend some of the time you saved fitting the kit around a screen it never expected.
Bolt runs the project inside the browser, which lines up neatly with a tool that also runs inside the browser: the preview is the real thing, so opening a real document and signing it is the same action as testing it. Plan Mode is worth using once, on the placement arithmetic.
Estimate your exact build timeframe
Plenty of genuinely useful signers ship without half of this. One that opens a single page, takes one signature, and exports is a real tool and a much shorter build. Untick what you are leaving out. The total is our own estimate rather than a quote.
Your estimate
55 hrs
start to finish
Based on the 5 of 5 features you’ve selected, plus ~4h of groundwork. Toggle any on the left to watch the number move, and open the groundwork row to untick what you have already, such as a database that is already running or going live if you are only building a mock-up for now.
A rough estimate, not a quote. Real time depends on how much you customize and how clean your data is.
Let’s set up the tools you need
Three things before step 01, and the first one is not optional here: Bolt only opens a project from a GitHub repository. There is no database card, because this build creates no database. The fourth card is not a service to join, it is four documents to have open while you work.
GitHub account
Bolt has no upload button for a folder or a .zip, and the only way to open a project is to import a repository, so a home for the code has to exist before Bolt does. Sign up and create a private repository, then push your project’s files to it.
Create a free GitHub accountBolt account
Sign up at bolt.new and connect the GitHub account from the step above. Once it’s linked, you pick a repository to import and land straight in a live preview, with nothing to install.
Sign up for BoltBolt subscription
Free gives you 300,000 tokens a day, capped at 1 million a month, which is enough to try Bolt rather than to finish a real app. Pro starts at $25/month for 10 million tokens (unused ones roll over one extra month), but Bolt reloads your whole project as context on every message, so a multi-session build tends to burn past that entry rung faster than the sticker number implies.
Compare Bolt plansA few real PDFs to test with
The only preparation this build actually needs, and the one that saves the most time. Find four documents on your own machine before you start: one of several pages, one that came out of a scanner rather than a word processor, one in landscape, and one large enough to be awkward. Those four break more signers than any prompt you will write, and having them open turns each fix into a two minute check rather than a guess.
Nothing here takes long. A GitHub account, a Bolt account, and a plan. Everything after that happens in the tab, and the repository stays in step on its own.
Build your signer, prompt by prompt
No code to write. You describe a piece and the running app rebuilds itself in the same tab. The order matters here more than on most builds: the placement arithmetic is step 04 rather than step 06, because everything after it is checking that it worked.
- 01
Get the project in, and set the rule
A repository imported into the tab, the two libraries that read and write PDF files added, and one instruction that governs everything after: nothing gets uploaded.
PromptSet up the projectSet this project up as React 18 and TypeScript with Tailwind, a library that renders PDF pages to the screen, and a library that writes into an existing PDF file. There is no database, no accounts, no environment variables and no server here, and none should be added: if you scan for environment variables on import, there genuinely are none. One rule for the whole project: no file the user opens may ever be sent anywhere. If something I ask for later would need a network call, tell me before you write it.
Bolt asks about environment variables when a project arrives. This one has none, so leave those fields empty and say so in the first message.
- 02
Open a real document and show it
A file taken in and rendered legibly in the tab, with zoom and page navigation. Use the awkward documents from the setup section rather than a one-page sample, because this step looks finished on one page and is not.
PromptBuild the viewerBuild the screen: a drop zone that also opens a file picker and takes one PDF at a time. Check the file really is a PDF rather than trusting its name, and show a clear message when it is not. Render its pages one under another at a readable width, with zoom between roughly half and double size, a page count, and a way to jump to a page. Read the file locally and make no request carrying its contents. Then tell me what happens today with a fifty page document, before changing anything about it.
Drop a real fifty page document into the preview. It is the actual tool running rather than a picture of it, so what you see there is what a visitor gets.
- 03
Draw the signature
A canvas that follows a mouse and follows a finger better. Open the preview address on your phone for this step, because the desktop version passes while the phone version does not.
PromptBuild the signature canvasAdd a signature pad: a canvas I can draw on with a mouse, a trackpad or a finger, using pointer events so all three behave the same. Undo the last ten strokes one at a time, and a clear button. Stop the page scrolling while a finger is drawing, size the canvas to the device pixel density so the line is not soft on a phone, and produce a transparent PNG. Then tell me how to open this preview on my own phone.
Transparent matters. A signature on a white rectangle covers whatever sits under it, and you find out when it lands across a line of text.
- 04
Place it, and get the coordinates right
The step this build turns on, and the one worth talking through before any code is written. Dragging the signature onto the page is the visible half. The other half is that where you dropped it and where it gets written use different units measured from opposite corners.
PromptPlan the maths, then place the signatureUse Plan Mode for this one before writing anything. I want to drag the signature onto any rendered page, keep it inside that page, remember which page it landed on, and allow more than one per document. The part I want planned is the conversion: what I drop is in screen pixels at the current zoom from the top left, and a PDF is written in points, seventy-two to the inch, from the bottom left. Tell me how you intend to derive it from each page’s rendered pixel size against its real point size, where the zoom gets divided back out, and which single function both the preview and the export will call. Then build it.
Plan Mode earns its keep exactly once in this build, and this is where. Read the plan, because a wrong version of these four lines still runs.
- 05
Write the signed file
Everything above exists to produce one file. Download it from the preview and open it in a reader you did not build, because the preview shares its assumptions with the code that would have got it wrong.
PromptExport itAdd the export: embed each placed signature into the original PDF at the position and size that shared conversion function returns, and download the result under a sensible name, with a way to download the untouched original too. All in the browser, with no upload. Then give me a check I can repeat: sign the same spot on a landscape page, a scanned page, and a page at double zoom, and show me the point coordinates written for each so I can compare them with where I dropped it.
Open all three in a desktop reader and on a phone. Right in the preview and wrong in a real reader is a genuine failure here.
- 06Destination
Keep the work, then publish
Two changes left, then it publishes from the same tab. The first stops a refresh throwing away somebody’s work. The second stops the tool needing a third party’s file to display a document at all.
PromptSurvive a refresh, and go offlineTwo changes. First, keep the opened document and the drawn signature across a page refresh, with a clear button that removes both deliberately, and handle a file too large for the browser store by telling me rather than failing quietly. Tell me what the real ceiling is. Second, copy the renderer’s worker file into the project and point the code at it instead of the public address it uses now, so the tool works with no network at all, and confirm the version matches.
The second change is what makes this work on a locked-down work laptop, which for some of the people who want this tool is the only laptop there is.
PromptPublish itPublish this, and tell me whether Bolt’s own hosting or Netlify suits me better given that I want my own domain on it eventually. Then tell me what to check on the published address rather than in the preview: open it with the browser network panel recording, sign a document, and confirm every request goes to my own files. Finish with what to improve next in priority order and which one you would do first.
The network panel check on the published address is the whole promise of this tool, and it takes about a minute.
Client-side security & risk model
No accounts, no database, no server of your own, and no request carrying a document anywhere. That removes most of what normally goes wrong. What is left is worth reading, because it is not nothing.
Most failure modes structurally absent
No sign-in means no passwords, no session to steal, and no privilege to escalate. No database means nothing to inject into. No server of yours means nothing to patch. This build starts safer than anything else we publish, and that is a property of its shape rather than of care taken with it.
Everything shipped is public
A static site hands every file it is made of to whoever opens the page. There are no secrets in this template and the rule to internalise is that there cannot be: anything pasted into the project is readable by anyone who views the source. If a later feature needs a real key, that piece has to move to a function on a server.
How to verify zero data leaks
The whole promise is that the document does not leave the device, and the way to know is to look rather than to trust. Open the browser’s network panel, sign a document from start to finish, and confirm the only requests are the page’s own files. Five minutes, and it is the one thing you should be able to state with certainty.
One file does come from elsewhere
The renderer loads its worker from a public address by default, which is a request to a third party on every visit. It carries no document and nothing identifying, and it is still a dependency and a privacy footnote. Bundling it into your own build removes both, and makes the tool work with no network at all.
A signature image is worth stealing
The picture somebody draws is reusable on any other document. Holding it in the page for the length of one session is reasonable. Keeping it somewhere durable, or leaving it in a shared browser profile, is the one genuinely bad idea available in a build with no server, so clear it deliberately rather than waiting for it to expire.
A valid signature, without the evidence
United States law defines an electronic signature as a symbol adopted with intent to sign, so a drawn mark placed on a page qualifies, and European law takes a similar position while reserving automatic equivalence with a handwritten signature for a higher tier. What is missing is everything around the mark: no verified identity, no timestamp anybody else attests to, nothing showing the file is unchanged. Both sources are in the references below.
The file you hand back is a real PDF
Writing into a document means writing into a format with a long and interesting history of parser bugs, so check your output in more than your own viewer. A signed file that opens in a browser and fails in a desktop reader is a bug your users will report and you will never have seen.
No backend still means a supply chain
The page is static once built, and building it pulls in packages that end up inside it. The two libraries that read and write the document are the ones that matter here, and one of them is version-pinned for a reason worth reading before you upgrade it. Keeping dependencies current is the only ongoing maintenance a build like this has.
Read this project the way somebody sceptical of its privacy claim would. List every network request the finished page makes, including anything a library fetches while loading, and say for each one what it sends. Then list everywhere the opened document and the drawn signature are held while the page is open, how long each of those survives, and what clears them. Finally, list every value in the project that ends up readable in the built files and should not be.
Worth running twice: once before you publish, and again the first time you add a library. What this page ships and what it fetches is the whole story, and both of those change without anybody deciding they should.
One rule outranks the rest: nothing in this project is private, because a static site hands every file it was built from to whoever opens the page. A value that has to stay secret belongs behind a function on a server rather than in the code.
What speeds the build, and what slows it
Speeds the build
- Using Plan Mode to talk a change through before Bolt writes any code
- Pointing a prompt at specific files or functions instead of the whole project
- Clearing Bolt’s context between unrelated features, so each prompt has less to process
- Checking the live preview after each change, since it’s the running app itself
- Reading the automatic GitHub commits later as a real history, not just a backup
Slows the build
- Asking for a whole app in one prompt instead of one screen or rule at a time
- Leaving context loaded from a finished feature while starting an unrelated one
- Editing the repository directly on GitHub and expecting Bolt to pick it up before its next 30-second check
- Approving several prompts in a row without checking the live preview after each one
GitHub: the way in, not just a backup
Bolt can’t open a .zip file, so the only way to start a project is to import a GitHub repository. Every other tool in this set treats GitHub as optional, but Bolt treats it as step one.
Why this comes before Bolt
There’s no upload button for a folder or a .zip. Opening a project in Bolt means pointing it at a repository that already exists on GitHub, so a home for the code has to exist first.
Create a free account, then a repository
Sign up, then create a new, private repository for your project and push your files to it. Keep it private, and never commit secret keys or passwords.
Create a free GitHub accountImport it into Bolt
On bolt.new, connect your GitHub account, choose the repository from the list, and click “Import repository”. The project opens straight into a live preview.
After that, it stays in sync on its own
Bolt commits each working change back to that repository automatically, and checks GitHub every 30 seconds for anything pushed from outside it. A commit is a snapshot with a short note, like “added the home page,” and Bolt writes those notes for you.
Version control and GitHub, Bolt docsIt’s also how you leave, if you ever want to
The repository Bolt is syncing is a real, ordinary codebase: clone it, hand it to someone else, or keep working on it directly on GitHub whenever you’re away from the browser tab.
Where to host your application
Hosting gives your app a home on the internet so anyone can open it via a web link. Choose a service below to make your site live. (There is no database here. Every document stays on the machine that opened it, so the host is the only service this build needs.)
| Host | Best for | Notes | Free tier |
|---|---|---|---|
| Vercel | One-click deploys | Connect the project and it publishes on every push, with a standard Vite build needing no configuration. The template already ships the routing rule Vercel wants, so a deep link resolves rather than 404ing. Check the plan terms before you commit: Hobby is personal and non-commercial, so a signer you put in front of clients belongs on Pro from $20/user/mo. | Pro from $20/user/mo (Hobby is non-commercial) |
| Netlify | Drag and drop, or Git | Connect the repository, or drop the built folder straight onto the page, which is genuinely the fastest way to get this in front of somebody this afternoon. You add the routing rule yourself here, since the one in the project is written for Vercel. | Free tier |
| Cloudflare Pages | Serving it from nearby | Files served from wherever is closest to whoever opened them, which suits a tool people use for two minutes and close. Its rules and headers configuration is also the most straightforward of these for the one security header this build benefits from. | Generous free tier |
| GitHub Pages | Free Git-based hosting | Publishes from the repository once one routing setting is changed. The usual catch, that free publishing needs a public repository, costs you less here than anywhere else in our catalogue: there are no keys in this project and no data in it either, so a public repository gives away code and nothing else. | Free from a public repo only |
| Firebase Hosting | One command to publish | Configure it once, and after that each release is a single command. Nothing this build does asks for anything Firebase offers, so the row is here for readers whose other projects already live there and who would rather keep one dashboard. | Free Spark tier |
| AWS Amplify Hosting | Teams already on AWS | Connect the project in the AWS console and set the one redirect rule a client-side route needs. The reason to pick this is almost always that somebody has already decided which cloud your organisation uses, rather than anything about a signer. | Free tier (build + hosting) |
| Surge | Publishing from the terminal | One command puts the built folder on an address, with no repository involved at all. Useful for handing a colleague something to try before you have decided where it will really live. | Free, unlimited publishing |
| Your own network | Documents that may not leave the building | The option the other seven cannot offer, and the reason some readers are here at all. The build is static files, so any internal web server will serve it, and a signer only reachable from inside your network is the strongest version of the promise this tool makes. | Whatever your server already costs |
Any of these will serve it. Two things to check rather than assume: whether the free tier allows commercial use, and how the host lets you set response headers, because a content security policy is the one piece of configuration this build genuinely benefits from.
The failure to expect on launch day is a document that will not display, on a build that worked perfectly on your machine. The renderer fetches its worker file from a public address as the page loads, so anything that blocks that request shows an error where the document should be: a strict content security policy, a company network, a laptop with no connection, or a version mismatch after a dependency update. Test it by opening the published address with that host blocked. Bundling the worker into your own build removes the failure completely, and it is the fix worth making before you publish rather than after somebody reports it.
Adding AI features without building a backend
A static page has nowhere to keep a provider key, so the first prompt below adds the one function everything else goes through. The last prompt needs no key at all.
The one function, before anything else
Every feature under this one needs a provider key, and a static page has nowhere to keep one. A single function on the host you already use is the whole of the backend this tool will ever have. It is also where the privacy claim changes shape, because whatever passes through it has left the machine, so choose which features earn that and put the answer on screen rather than in a policy nobody opens.
Add one serverless function to this project, the smallest kind my host supports, and nothing else. It should take a short piece of text, pass it to an AI provider using a key read from the host’s own environment settings, and return the answer. That key must never appear in anything the browser downloads, and the function must never receive a whole document, only text I have chosen to send it. Show me where to paste the key in my host’s dashboard rather than anywhere in the project. Then add a line in the interface, visible before the first send, naming exactly which actions move document text off this machine.
A summary before you sign
The most useful thing a model can do here is tell somebody what they are about to put their name on: the parties, the term, the money, the notice period, and anything unusual. It needs the document’s words, which this build deliberately does not read at all, so the prompt turns text extraction on as part of the same change.
Turn on text extraction in the PDF viewer so the page can read the words on each page, then add a "Summarise this document" action that sends the extracted text through the ai function and shows what comes back above the document: the parties, the dates, the amounts, the notice period, and anything that looks unusual, each with the page it came from. Warn the reader before the first send that this action uploads the document text, and make it a choice rather than something that happens the moment a file opens.
Finding where to sign
A long agreement hides its signature blocks, and hunting for them is the slowest part of signing anything over ten pages. Extracted text and a model together are good at spotting the phrases that mark them, and the result is a list of page numbers to jump to rather than a scroll and a guess.
Using the extracted text, add an action that finds the likely signature locations in the document (signature lines, initials boxes, date fields, anything introduced by wording like "signed by" or "authorised signatory") and returns a list of page numbers with a short description of each. Show it as a jump list beside the document. Say plainly in the interface that it is a suggestion rather than a guarantee, and never place a signature automatically on the strength of it.
A plainer reading of one clause
The narrowest version of the same idea, and the one people actually ask for: select a paragraph, get it back in ordinary words. Sending one clause rather than a whole contract is a much smaller trade than the summary asks for, which makes this the easiest of these to justify to somebody cautious.
Let me select a region of the page and send only the text inside that selection through the ai function, asking for the same clause in plain language plus one line on what it would mean for the person signing. Show the original and the rewrite side by side, make clear on screen that it is not legal advice, and send nothing at all beyond the selected text.
Better handwriting, with nothing sent anywhere
The one item here that needs no function, no key and no upload. Smoothing a drawn stroke is ordinary geometry, and it is the difference between a signature that looks signed and one that looks like it was drawn with a mouse, which is what most of them are.
Improve the signature canvas without adding any network calls at all. Smooth the drawn path as it is captured so a stroke made with a mouse or a trackpad reads as a pen line rather than a series of straight segments, let the line weight respond to speed, and render at the device’s own pixel density so it is not soft on a high-resolution screen. Keep every part of it local: no library that phones home, and no request of any kind.
Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.
Get a head start with our template
Everything above is the build itself. If you would rather start from something already running, our template ships the viewer, the drawing canvas, the placement and the export working, so your time goes on what you actually wanted to change.
PDF Signature Tool
The exact PDF signer this guide builds, packaged so you can open it, point it at your own backend, and make it yours from there. A private, no-fuss way for individuals and teams to sign PDFs - no printing, scanning, accounts, or external services. It all happens in the browser: open a document, place your signature where you want it, and download the finished file, with nothing ever leaving the device.
The key benefits of starting with a template
The hardest technical features (PDF rendering, smooth touch signatures, and drag-and-drop page placement) are completely pre-built. You only need to customize the UI and branding.
Building the signer from scratch
~55 hrs
Opening the template, already built
~1 hr
~54 hrs of building you skip
These measure different things on purpose: the first is building the tool, the second is opening and running one that already exists. Two jobs sit on neither side, because you do them either way. The export placement arithmetic needs correcting, and the shipped page promises a typed signature the code does not have yet. Both are named in the guide above, with the prompt for each.
A working signer, today
Open a document, render it, zoom, draw, drag, place on any page, export a signed file. All of it running before you have written a line, which on a build whose hard part is one conversion is worth more than it sounds.
Nothing at all to configure
No database, no keys, no environment file, no account anywhere. Install the dependencies, start it, and the tool works. That is genuinely rare in our catalogue, and it is why this one goes from purchase to running in minutes.
Touch handled, not promised
The drawing canvas works with a finger as well as a mouse, with undo across ten strokes, which is the part everybody assumes is easy and then spends a day on. Checked on real devices rather than by making a browser window narrow.
Clean code that is easy to extend
React and TypeScript with a full component library installed and mostly unused, deliberately, so the next thing you ask your AI coding tool for has parts to build from. One dependency is imported nowhere at all and is safe to delete.
From founders who build on our templates
We needed a document signing solution where files strictly never touch external servers. This template was the perfect fit: we deployed it as a static site with zero hosting costs and total data privacy.
Jeevan ThomasFounder & CEO, Hado.aiCommon questions
Yes, and it is checkable rather than a promise. The file is read off the disk by the browser, drawn by code running in the page, marked with a canvas element, and written back by a library that also runs in the page. No request carries it anywhere. One file does come from a third party while the page loads, the renderer’s worker, and it carries nothing of yours. Open the browser’s network panel and sign a document to watch all of this for yourself in about a minute.
In the ordinary case yes, and this is not legal advice. United States law defines an electronic signature as a symbol adopted with intent to sign, and says a record cannot be refused legal effect purely for being electronic. European law recognises three levels and takes much the same position, while reserving automatic equivalence with a handwritten signature for the highest one, which needs a qualified certificate this build does not issue. So what you get here is a signature. What you do not get is evidence about it, and on a document somebody might dispute, that is the part that matters. Some document types sit outside these rules altogether, so check the ones you care about.
Evidence, and a meter. A platform records who opened the document, when, and from which address, then seals the file so a later change is detectable, and sells you that record. This tool places a signature and hands you the file. For your own paperwork the record is usually worth nothing and the meter is worth avoiding. For a contract somebody might contest, the record is the entire reason to pay.
Not in this build, and it is worth understanding why rather than reading it as a gap. The moment a second person is involved you need a way to reach them, a way to know it was really them, and somewhere for the document to wait in between, which means a server, an identity and storage. That is a different application with a different shape and a much longer build. What you can do today is sign your own copy and send it however you already send files.
Not as it stands, and the shipped interface says otherwise in two places, which is worth knowing before a colleague points it out. Adding it is a small, well-defined change: a text field, a handwriting typeface, and the same image path the drawn version already uses. The guide above includes it as an explicit step rather than assuming it is there.
No, and this one is structural rather than a missing feature. The viewer deliberately draws pages as images with the text and annotation layers switched off, so there is no selectable text, no clickable link, and no form field to fill in. It puts an image on top of a page. A form filler is a genuinely different build, and the marketing text in the template’s own page header is wrong about this.
Because of the one real bug in the template, and it is worth fixing early rather than working around. Where you drop the signature is measured in screen pixels at whatever zoom you are on. The finished PDF is written in points, from the opposite corner of the page. With no conversion between the two, the placement drifts further as you move away from the top left and further again as you zoom in. Step 04 of the guide above is entirely about this.
Larger than you would expect to open, and smaller than you would expect to survive a refresh. The interface advises ten megabytes and nothing in the code enforces it. Separately, keeping your work across a refresh means holding the document in a small browser store that most browsers cap around five megabytes of text, so a large file can silently fail to come back. Decide a limit, show it, and check it.
Close to nothing, and this is the cheapest thing to run in our whole catalogue. Static hosting is free on several of the hosts above, subject to their plan terms. There is no storage, no mail provider, and no per-document charge, because there is nothing in the middle to charge you for one. If you add one of the AI features you pay the model provider for the text you send it, and only then.
No, and the contrast with renting is sharper here than on most builds. What you end up with is an ordinary folder of files: move it between hosts in an afternoon, put it on a machine inside your own network, hand it to a developer, keep it through the next procurement review. Nothing about it depends on a company staying in business or holding its current prices.
No. You describe what you want in the chat and Bolt writes the code and shows it running in the same tab. The one extra step Bolt asks for that other browser tools do not is a GitHub account, since that is how a project gets in. The setup section above covers it, and there is no database step in this build.
Bolt only opens projects from a GitHub repository, and it offers no upload button for a folder. Once it’s imported, Bolt keeps the two in sync automatically, so the extra step up front replaces a manual export later.
Free resets daily, and a paid plan’s monthly allotment resets on your billing cycle (unused Pro tokens also roll over one extra month). If you hit the cap mid-session, what you’ve built stays exactly as it is. You wait for the reset or buy more tokens to keep going right away.
References
Sources checked August 2026- 01Data Breach Investigations Report 2026 (third-party involvement), Verizon. verizon.com (published May 2026)
- 02Acrobat Sign transaction limits (150 per user per year), Adobe. community.adobe.com (published July 2026)
- 03eSignature plans and envelope allowances, DocuSign. ecom.docusign.com
- 04Plans and pricing (signature requests by plan), Dropbox Sign. sign.dropbox.com
- 05Can I use Dropbox Sign for free? (free plan limits). help.dropbox.com
- 06Pricing (per-tool limits and file-size caps), iLovePDF. ilovepdf.com
- 07FAQ (how long uploaded files are kept), iLovePDF. ilovepdf.com
- 0815 U.S.C. 7001, general rule of validity for electronic records. law.cornell.edu
- 0915 U.S.C. 7006, definition of an electronic signature. law.cornell.edu
- 10Trust services under the European Digital Identity Regulation, European Commission. digital-strategy.ec.europa.eu
- 11PDF.js, the renderer built into Firefox. github.com
- 12pdf-lib, create and modify PDFs in any JavaScript environment. pdf-lib.js.org
- 13Web developer hourly rates 2026 (freelance and agency benchmarks). developex.com
- 14Pricing (Free, Pro, Teams), Bolt. bolt.new
- 15Version control and GitHub, Bolt docs. support.bolt.new
- 16What is Bolt Cloud?, Bolt docs. support.bolt.new
- 17Netlify deployment (and Bolt hosting by default), Bolt docs. support.bolt.new
- 18Maximizing token efficiency, Bolt docs. support.bolt.new
This guide is general information and not legal advice: whether a particular signature satisfies a particular law, for a particular document, in a particular country, is a question for somebody qualified there. Third-party prices, plan limits, and market rates are quoted from the sources above and were last checked on the date shown. Vendors change them without notice, so confirm before you budget. Adobe publishes plan limits we could read and prices we could not, so this guide quotes the limits and no dollar figure at all rather than borrowing one from a comparison site. Build hours and the cost estimates derived from them are our own estimates, not quotes. Bolt is a product of StackBlitz. Verify current capabilities and pricing before relying on them.