Build with AI

How to build a PDF signature tool with Lovable

Create a fully private PDF signer just by chatting. Lovable generates the UI, handles complex coordinate positioning, and deploys your web app instantly: no coding or hosting setup needed.

August 2026 · 47 min read · Updated September 2026

Lovable

$ 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 and canvas in the preview
Placement maths corrected
Ready for you to review

You describe it, Lovable builds it

Start here

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

What a PDF signer needs

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.

Build vs buy

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 · iLovePDF

A 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

DocuSign$11/mo (Personal) to $45/user/mo (Business Pro), annual

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

Dropbox SignFree, then $10.05 to $25 per user per month

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 Acrobat SignNo dollar figure quoted here

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

iLovePDFFree, then EUR 9/mo or EUR 60/yr

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.

No dev needed

Why build with Lovable

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.

Lovable turns that into a conversation with the running tool next to it: describe a piece, watch it appear in the preview, and use it before asking for the next one:

The build loop

Prompt

Say what you want to add or change, in plain language.

Watch

The live preview rebuilds in the browser as Lovable writes the code.

Try it

Click through the real app, with real buttons, forms and data rather than a mockup.

Refine

Select what’s off and describe the fix, or ask for what’s next.

Loop back to Describe

None of that requires a computer science background or writing code, and the whole build happens in one browser tab, 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 in this build, and the preview is where you see whether it worked, because a signature in the wrong place is obvious the moment you look at it.

Click to point instead of describing where

Select any element in the live preview with Lovable’s Select elements tool, and your next message applies to exactly that piece.

Full ownership and complete privacy

The app and the records in it are yours. Every change is saved automatically, and the repository Lovable syncs to GitHub is private on every plan, with no technical setup and not one Git command.

What it costs

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 Lovable

From scratch, with Lovable

Lovable: Free (30 credits/mo) to $25+/month (Pro, from 100 credits)
Hosting: $0 on a Lovable subdomain
Your time: ~55 hrs

Free to try the idea, ~$25-$50+/month on Pro while you build a real one, then whichever credit tier you keep using

Lovable bills by credits, so what you pay tracks what you build: importing the pre-built template can fit inside the Free plan’s 30 credits a month, while a full from-scratch build burns through Free fast and usually needs Pro. Pro’s entry rung is $25/month (or $250/year, roughly $21/month effective) for 100 credits, the bottom of a ladder where 200 credits runs $50/month (or $500/year, about $42/month), and a multi-session build often lands on that rung or higher rather than the entry price.

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 docs.lovable.dev, checked August 2026.

Plan first

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.

Approaches

Comparing your build options

What you start from decides how much of this goes on the one hard part and how much on structure nobody sees. The same tool three ways: from nothing, on a kit with opinions of its own, or described to Lovable one piece at a time.

~115 hrsBuilding by hand

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.

~85 hrsGeneric UI starter kit

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.

~55 hrsBuilt with Lovable

Describe a piece and it appears in the preview beside the chat, running. That is worth more on this build than on most, because the two things that go wrong here (a canvas that feels wrong under a finger, a signature half an inch off) are both things you find by using the thing rather than by reading it.

Interactive calculator

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.

What your PDF signer needs

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.

Setting up your workspace

Let’s set up the tools you need

Three things to connect before step 01, and one of them is optional. There is no database card here, 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.

Lovable account

Free

Nothing to download. Sign up with an email, Google, or GitHub account and you land straight in the chat where you describe what to build.

Lovable subscription

$25/month (Pro) and up

Lovable bills by build credits, so the plan you need follows what you build. Free gives you 5 credits a day, capped at 30 a month, which is enough to try it rather than to finish an app. Pro is $25/month for 100 credits ($250/year, about $21/month), and that is the bottom rung: a build spread over several sessions usually lands on 200 credits at $50/month, or higher.

Compare Lovable plans

Optional

GitHub connection

Free

Not needed to build anything, since Lovable keeps its own history of every change. Link a GitHub account and it also keeps a private repository in sync, so a copy of the real code exists outside the browser tab. Worth doing before the project is one you would hate to lose.

Set up GitHub sync

A few real PDFs to test with

Free

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. An account, a plan, and a GitHub connection you can add whenever you want a private copy of the code. Everything after that happens in the chat.

Step by step

Build your signer, prompt by prompt

No code to write. You describe a piece in the chat and it appears in the preview, running. 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.

Start the project and set the rule

A running project with the two libraries that read and write PDF files in it, and one instruction that governs everything after: nothing gets uploaded.

PromptSet up the project

Start a React and TypeScript project with Tailwind, a library that renders PDF pages to the screen, and a library that writes into an existing PDF file. This tool has no database, no accounts, no environment variables and no server, and must not acquire any. One rule for the whole project: no file the user opens may ever be sent anywhere. If a later request would need a network call, tell me before you write it rather than adding it quietly.

Say the rule once, at the start, in the project itself. It is the claim this whole tool makes, and it is the easiest thing to break by accident three requests later.

Open a real document and show it

A file taken in and rendered legibly in the preview, with zoom and page navigation. Open the awkward documents from the setup section here rather than a one-page sample, because this step looks finished on one page and is not.

PromptBuild the viewer

Build the first 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 you change anything about it.

Drop a real fifty page document into the preview yourself. That is the check, and the preview is the actual tool rather than a picture of it.

Draw the signature

A canvas that follows a mouse and follows a finger better. Open the preview on your phone for this one, because the desktop version of this step passes while the phone version does not.

PromptBuild the signature canvas

Add 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 so I can try it with a finger.

Transparent matters. A signature on a white rectangle covers whatever sits under it, and you will find out when it lands across a line of text.

Place it, and get the coordinates right

The step this build turns on. Dragging the signature onto the page is the visible half and it looks like the whole thing. The other half is that where you dropped it and where it gets written are measured in different units from opposite corners.

PromptPlace the signature, then fix the maths

Let me 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. Then the part that decides whether this tool works: what I drop is in screen pixels at the current zoom, measured from the top left, and a PDF is written in points, seventy-two to the inch, measured from the bottom left. Work the conversion out from each page’s rendered pixel size against its real point size, divide the zoom back out, and put it in one function that both the preview and the export use. Then explain that conversion to me in plain words.

Bookmark the version before this message. This is the change most likely to need a second attempt, and a bookmark makes the first attempt free.

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 it

Add 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 as well. 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 and a common one.

Destination

Keep the work, then publish

Two changes left, and then it goes live from the same chat. The first stops a refresh throwing away somebody’s work. The second stops the tool needing a third party’s file to show a document at all.

PromptSurvive a refresh, and go offline

Two 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 it

Publish the project, 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. Then walk me through putting it on my own domain, and list what to improve next in priority order with the one thing 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.

Security & privacy

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.

PromptAudit what actually leaves the page

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.

Workflow rules

What speeds the build, and what slows it

Speeds the build

One small request per message, such as the canvas or the export, rather than the whole tool at once
Testing every change with a real document from your own machine, not a one-page sample
Using Select elements to point at the exact control that should change, instead of describing where it sits
Bookmarking a known-good version before you touch the placement arithmetic
Reading each response before sending the next request, so small mistakes do not stack up

Slows the build

Asking for the whole tool in one message instead of one piece at a time
Judging the drawing canvas by using it with a mouse
Describing which button to change instead of selecting it
Skipping bookmarks, then scrolling far back through history to undo a bad change
Approving several messages in a row without opening the exported file

Keeping a safe copy

Connecting GitHub (Optional)

Every change in Lovable is saved automatically without any technical setup. You only need to link GitHub if you want a private copy under your own control or plan to hand the codebase over to external developers.

What Git actually is

A recorder for a project: every change becomes a version you can go back to, and nothing is ever overwritten. GitHub is the service that keeps those versions online.

Lovable already saves every change

A new version is created each time Lovable changes your project. No save button, no Git command, and the full history is there to scroll back through.

Version history, Lovable docs

Reverting is safe on this build

One click restores an earlier version of your code and redeploys it. On most projects you then have to think about records already written, and on this one you do not, because nothing this tool produces is stored anywhere except the browser it was opened in.

Bookmark before a big change

Before a redesign, or before you touch the placement arithmetic, bookmark the version you are on: one click back rather than a long scroll through history.

Connecting it, if you want to

Open your project settings, pick GitHub, and authorise the account. Lovable creates a private repository and keeps it in sync both ways: changes in Lovable reach GitHub, and anything pushed to that branch comes back in. Free on every plan.

GitHub integration, Lovable docs

It’s also how you leave, if you ever want to

The synced repository is a standard Vite and React project: clone it, hand it to a developer, or deploy it yourself.

Deployment, hosting, and ownership, Lovable docs

Going live

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
LovableBuilt in	Publishing from the chat	The project you have been previewing publishes itself, with nothing to configure and no account to open anywhere else. Free on any plan at a lovable.app address. Paid plans put it on your own domain: buy one through Lovable and the DNS is done for you, or point one you already own at it using the two records the setup screen shows. Certificate issued automatically either way.	Free on a lovable.app subdomain · own domain on paid plans

One button, and the app you have been previewing is live.

Optional

Hosting it somewhere else

Only for a setup Lovable does not offer: a host you already pay for, or the exported code on your own account. None of it is needed to go live.

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.

AI workflows

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.

PromptThe one function, before anything else

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.

PromptA summary before you sign

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.

PromptFinding where to sign

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.

PromptA plainer reading of one clause

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.

PromptBetter handwriting, with nothing sent anywhere

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.

You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.

Ready-made option

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.

React 18ViteTypeScriptTailwind CSS

Get template - Free Open live demo

Out of the box

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.

Customer story

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.ai

Got questions?

Common 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. Everything happens in a browser tab: you describe what you want in the chat, and Lovable writes the code and shows it running beside you. The setup section above covers the two things you connect first, an account and a plan, and there is no database step in this build.

A sketch on the Free plan is fine for agreeing what the screen should look like. It is not where you finish, because the part that decides whether this tool works is the placement arithmetic, and getting that right means running real documents through it repeatedly on a plan that lets you keep going.

Build credits reset every day (Free) or on your billing cycle (paid plans). If you run out mid-session, the app you’ve built stays exactly as it is. You either wait for the reset or move up a credit tier 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
14Sign up, Lovable. lovable.dev
15Subscription plans (Free, Pro, Business), Lovable docs. docs.lovable.dev
16GitHub integration, Lovable docs. docs.lovable.dev
17Deployment, hosting, and ownership, Lovable docs. docs.lovable.dev
18Version history and reverting, Lovable docs. docs.lovable.dev
19Preview toolbar (Select elements), Lovable docs. docs.lovable.dev
20AI features and model selection, Lovable docs. docs.lovable.dev
21Custom domains, Lovable docs. docs.lovable.dev

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. Lovable is a product of Lovable Labs. Verify current capabilities and pricing before relying on them.