Web design projects go sideways in a predictable pattern. The client loved your portfolio. The kickoff call went great. Then the project started, and suddenly the scope is three times what you quoted, the feedback rounds are endless, and you're not sure what you actually agreed to deliver.
A web design contract doesn't prevent difficult clients. But it does make "we agreed to X" a statement you can point to — and that changes everything.
This guide covers every clause a web design contract needs, what each one actually does, and the situations where they matter.
The Core Sections Every Web Design Contract Needs
1. Parties and Project Summary
Open with the legal names of both parties — your business name (or your name, if you're a sole proprietor) and the client's legal entity name, not just a contact person.
Follow that with a one-paragraph project summary: what you're building, the general purpose, and who the contract is between. This isn't the detailed scope — it's the headline that frames everything that follows.
2. Scope of Work
This is where most web design disputes begin, and where your contract needs to be most specific.
List exactly what you're delivering: number of pages, whether you're doing copywriting or the client provides it, whether the design is for a specific platform (WordPress, Webflow, Squarespace), whether you're handling hosting setup, and whether you're building to a mobile breakpoint or just desktop.
Then list what's explicitly not included. SEO copywriting. Custom illustration. Third-party plugin licenses. Ongoing maintenance. If you don't name it, the client will assume it's included.
3. Revision Rounds
Web design has a specific problem most other freelance work doesn't: feedback rounds can spiral indefinitely.
Your contract should define the number of revision rounds included at each stage (typically two rounds at design, two at development) and what counts as a revision versus a new request. A revision is a change to something already designed. A new request is adding a feature or page that wasn't in the original scope.
State clearly that additional rounds are billed at your hourly rate.
4. Client Responsibilities
Web design is collaborative. Your contract should list what the client must provide and by when — logo files, brand guidelines, copy, images, domain access, hosting credentials.
Include a timeline dependency clause: if the client delays providing materials, the project timeline shifts accordingly. Without this, you can be held responsible for a delay that was entirely on their side.
5. Payment Schedule
Tie payment milestones to deliverable stages, not calendar dates.
A common structure:
50% retainer at contract signing
25% at design approval
25% at launch
This protects you from a client who ghosts after you've done the design work and refuses to pay because they "aren't happy yet." Stage-based payments mean partial work is always paid.
Specify late payment fees — typically 1.5% per month on overdue balances. Most clients never trigger this, but having it written creates urgency when invoices go past due.
6. Timeline and Launch Date
State a projected launch date and make clear it's contingent on client responsiveness — timely feedback, approvals, and content delivery.
Define what happens if the project stalls on the client's side. A common clause: if the project is delayed more than 30 days due to client inaction, you may restart billing or charge a reactivation fee.
7. Intellectual Property and Ownership
Until you are paid in full, you own the work.
This is the standard position in professional web design contracts, and it matters. If a client disputes the final invoice and refuses to pay, you retain the right to take the site down (or not hand over the files) until payment is received.
On full payment, ownership of the final design and code transfers to the client. However, specify that your underlying tools, frameworks, and codebase remain yours — you're licensing those components, not transferring them.
Also address portfolio rights: you retain the right to display the finished project in your portfolio and on social media.
8. Third-Party Tools, Plugins, and Licenses
Web projects almost always involve third-party tools — stock photos, premium plugins, fonts, APIs, hosting platforms.
State clearly that the client is responsible for any third-party licenses required to run the site after handoff. You're not responsible for a plugin vendor raising prices or discontinuing support six months after launch.
9. Browser and Device Compatibility
Define explicitly which browsers and devices the site will be tested on — typically the current versions of Chrome, Safari, Firefox, and Edge, on desktop and mobile.
You are not responsible for display issues in older browsers or on obscure devices not covered by your testing scope. Say that in the contract.
10. Post-Launch Support
Specify whether you're offering a support period after launch, and if so, how long and what it covers.
A 30-day bug-fix window is common: you'll fix bugs in the work you built, but new feature requests are billed separately. After 30 days, ongoing support requires a separate retainer agreement.
11. Confidentiality
If the client shares sensitive business information during the project — strategies, unreleased products, internal processes — a confidentiality clause protects them.
Keep it mutual: you may also share your methods or pricing with them that you'd prefer not to see shared publicly.
12. Termination
Both parties should be able to exit the contract. Define the process:
Client can terminate with written notice. They owe payment for all work completed to date.
You can terminate if the client fails to pay within a defined window (typically 14 days after a missed payment).
On termination, you deliver the completed work in exchange for final payment.
13. Limitation of Liability
You are not responsible for lost business, lost revenue, or reputational damage that results from a site issue.
Cap your liability at the total amount paid for the project. This is standard in professional contracts and courts generally uphold it.
14. Dispute Resolution
Require good-faith negotiation first, then mediation if that fails, before either party can pursue litigation.
Specify your state's law as governing and your county as the jurisdiction. This matters if a dispute ever goes to court — you don't want to be flying to another state to settle a $3,000 invoice.
Handling Scope Creep Before It Happens
Scope creep is when a project gradually expands beyond what was agreed — one extra page here, one new feature there — and suddenly you've done 40% more work than you quoted.
Your contract should include a change order clause: any change to the scope requires a written change order, signed by both parties, before work begins. You are not obligated to perform out-of-scope work without a signed change order.
When a client asks for something outside the original scope, the response is simple: "I'll put together a change order for that." It's professional, not confrontational.
Getting the Contract Signed Before Work Starts
No kickoff call. No design files shared. No domain access until the contract is signed and the retainer is paid. Both at the same time.
This is the professional standard, and clients who've worked with experienced designers expect it. Tools like FileCurrent let you send a contract with a built-in e-signature link — the client signs digitally, you're notified immediately, and the whole thing takes minutes.
E-signatures are legally binding under the federal ESIGN Act and UETA, which cover all 50 states.
Frequently Asked Questions
What should a web design contract include?
At minimum: scope of work (including what's not included), revision rounds, client responsibilities, payment schedule tied to milestones, IP ownership terms, browser compatibility scope, post-launch support terms, termination, and limitation of liability.
Who owns the website once it's built?
Until paid in full, you do. On final payment, ownership of the specific design and code transfers to the client. Your underlying tools, frameworks, and libraries remain yours — you're licensing those components, not handing over ownership.
How do I handle clients who keep requesting changes?
Define revision rounds in the contract and hold to them. The contract is your foundation: "we agreed to two design rounds; this is the third — I'll send a change order for the additional work." Most clients accept this without issue.
Is a web design contract legally binding if signed electronically?
Yes. The ESIGN Act (federal) and UETA (49 states plus DC) give e-signatures the same legal standing as handwritten ones.
What happens if the client refuses to pay?
If you have an IP clause stating ownership transfers on full payment, you have the right to take down or withhold files until payment is received. For persistent non-payment, small claims court is available for contracts under your state's threshold (usually $5,000–$10,000). A well-written contract is your evidence.
The Bottom Line
A good web design contract protects the project before it starts — and most of the time, it just lives in a folder. The times it matters, it matters a lot.
Get it signed before you open a design file. FileCurrent handles contracts and e-signatures in one place — 7-day trial, no card required. For a related read, see our consulting contract template if you also provide strategy or advisory work alongside development.
This article is for informational purposes and does not constitute legal advice. Consult a licensed attorney in your state for contracts specific to your business.