How to Write a Privacy Policy: The Complete 2026 Guide
The 12 sections every compliant privacy policy contains, how GDPR and CCPA and the newer state laws actually differ, how to disclose 60+ common third-party services, the emerging AI clauses, and when a generator is enough โ versus when you need a lawyer.
- Write a compliant privacy policy for your site.
- Why You Need a Privacy Policy.
- The 12 Sections Every Privacy Policy Needs.
- Covers gdpr vs ccpa vs the rest.
- Covers data categories and why they matter.
Why You Need a Privacy Policy
If your website collects a name, an email, an IP address, or a cookie โ you need a privacy policy. Not because it's a nice-to-have for credibility. Because it's legally required in most of the places your site is reachable from. GDPR applies to any service processing data from EEA residents, regardless of where the business is based. CCPA/CPRA applies to most for-profit businesses with California users. Virginia, Colorado, Connecticut, Utah, and Texas have their own laws. Brazil, Canada, the UK, Australia, Japan, Korea, Singapore, South Africa, and India all have their own privacy acts. You don't get to pick which ones apply to you; your users' locations do that.
A privacy policy is the legal document that discloses what you collect, why, who you share it with, how long you keep it, what rights users have, and how to contact you about those rights. Every modern privacy law requires this disclosure in accessible language. The consequences of not having one โ or of having one that doesn't match what your site actually does โ range from being locked out of Apple and Google app stores, to being banned from running ads on Meta or Google, to six-figure fines under GDPR.
This guide walks through the 12 sections every compliant policy contains, how the major laws differ, how to disclose 60+ common third-party services, and the new AI clauses that most generators still don't cover. The Privacy Policy Generator automates the template โ this guide explains what the template is actually doing.
The 12 Sections Every Privacy Policy Needs
A privacy policy isn't free-form prose. It's a structured disclosure document, and every modern privacy law expects the same core sections. The specific wording varies with jurisdiction, but the outline doesn't:
auto-fill and auto-fit behave differently when there are fewer items than columns. Use auto-fill to keep empty tracks; auto-fit to collapse them.- 1. Introduction and identity. Your legal business name, the service URL, and how users can reach you.
- 2. Information you collect. Every category of personal data you gather โ names, emails, IPs, device identifiers, behavioral data, payment info, location, sensitive data.
- 3. How you collect it. Directly from users, automatically from their devices, from third parties, via cookies and tracking.
- 4. Why you collect it. The purposes โ service delivery, billing, communications, analytics, marketing, fraud prevention, legal compliance.
- 5. Legal basis. Under GDPR specifically, you must name the legal basis for each purpose: consent, contract, legitimate interest, legal obligation, vital interest, or public task.
- 6. Who you share it with. Every third-party service that receives user data (Stripe, Google Analytics, Mailchimp, etc.), plus law enforcement disclosures and business transfer scenarios.
- 7. International transfers. If data leaves the user's jurisdiction, what safeguards apply โ Standard Contractual Clauses, Data Privacy Framework, etc.
- 8. Retention periods. How long you keep each category of data, and on what basis.
- 9. User rights. The specific rights that apply in each jurisdiction โ access, deletion, correction, portability, opt-out of sale, limit use of sensitive data, withdraw consent.
- 10. How to exercise rights. The method to submit requests, verification steps, response timelines.
- 11. Cookies and tracking. Cookie categories, purposes, how to opt out, browser controls.
- 12. Updates and contact. How changes are communicated, a Data Protection Officer if applicable, and a contact method for privacy questions.
A policy that's missing any of these sections is incomplete under at least one of the major privacy laws. Most commercial generators cover the first 8 and skip the newer requirements (sensitive data categories under CPRA, automated decision-making rights under GDPR Art. 22, AI-specific disclosures). The UDT generator includes all 12 and adapts the language per jurisdiction you select.
GDPR vs CCPA vs the Rest
Privacy laws are local, but the internet is not. If your users span multiple regions, your policy has to cover the strictest requirement in each. The five most commonly applicable frameworks:
background-size animation or @property registered custom properties instead.GDPR (EU/EEA) is the most demanding. It requires explicit legal basis for each purpose, grants eight specific rights including data portability and the right to erasure ("right to be forgotten"), and mandates a Data Protection Officer for many businesses. Response time for rights requests is one month. Penalties reach โฌ20M or 4% of global annual revenue, whichever is higher.
UK-GDPR/DPA mirrors GDPR with the UK ICO as the enforcement authority rather than EU DPAs. For most businesses, a GDPR-compliant policy also satisfies UK-GDPR with minimal adjustment.
CCPA/CPRA (California) grants six rights including opt-out of sale and sharing, plus a separate right to limit use of sensitive personal information (CPRA's 2023 addition). You must honor Global Privacy Control (GPC) browser signals. Response time is 45 days. Applies to for-profit businesses meeting revenue or data thresholds.
VCDPA, CPA, CTDPA, UCPA, TDPSA โ Virginia, Colorado, Connecticut, Utah, and Texas. Each is CCPA-adjacent but with variations. Virginia and Colorado require opt-out of targeted advertising specifically, not just sales. Texas (TDPSA, effective July 2024) has the broadest applicability of the US state laws โ no revenue threshold, just doing business in Texas.
LGPD (Brazil), PIPEDA + Quebec Law 25 (Canada), Australia Privacy Act, APPI (Japan), PIPA (Korea), PDPA (Singapore/Thailand), POPIA (South Africa), DPDP Act (India), FADP (Switzerland) โ each has its own rights framework and authority. If you serve users in any of these regions, add a jurisdiction-specific section to your policy naming the applicable rights and the supervisory authority.
Data Categories and Why They Matter
Not all personal data is treated equally under the law. Privacy laws distinguish between personal data (anything that identifies a person) and sensitive personal data (categories with heightened protection). Your policy has to be explicit about both, and especially explicit about sensitive categories if you collect them.
The common categories the generator helps you document:
- Identity data โ name, username, date of birth.
- Contact data โ email address, phone number, mailing address.
- Technical data โ IP address, browser fingerprint, device identifier, OS, referrer URL.
- Usage data โ pages visited, actions taken, session duration, click paths.
- Financial data โ payment card details, billing address, transaction history (subject to PCI-DSS, not usually stored by you if you use Stripe or similar).
- Location data โ coarse (city-level from IP) or precise (GPS coordinates).
- Biometric and health data โ fingerprints, face recognition, wellness inputs. These trigger enhanced requirements under GDPR Art. 9 and CPRA sensitive personal information rules.
- Sensitive identifiers โ SSN, driver's license, passport number, government IDs. Subject to extra state requirements (Massachusetts 201 CMR 17.00, etc.).
- Children's data โ COPPA applies to collection from users under 13 in the US; GDPR sets the threshold at 16 (with member state variations down to 13).
The test: if you collect any category, disclose it โ don't omit categories hoping users won't notice. Omission is a separate violation. If you use a third-party service that collects data you never see directly (Google Analytics collects IPs, Stripe collects full card numbers), you still disclose that collection in your policy because you are the "controller" directing the processor to collect on your behalf.
Disclosing 60+ Third-Party Services
Almost every modern website embeds third-party services: analytics, payments, email, advertising, CDN, authentication, customer support, AI, hosting, embeds. Each one that receives personal data must be disclosed by name, purpose, and a link to its own privacy policy. This is the section most cheap generators skip.
The UDT generator covers 60+ services across 11 categories:
- Analytics โ Google Analytics 4, Plausible, Fathom, Mixpanel, Amplitude, Hotjar, Clarity, Segment, PostHog, Heap, Google Tag Manager.
- Advertising โ Google Ads, Meta Pixel, TikTok Pixel, LinkedIn Insight, X Pixel, Pinterest Tag, Reddit Pixel, Snap Pixel, AdSense.
- Payments โ Stripe, PayPal, Square, Braintree, Razorpay, Apple Pay, Google Pay.
- Email โ Mailchimp, SendGrid, Postmark, Resend, ConvertKit, Klaviyo, HubSpot.
- CDN and hosting โ Cloudflare, AWS, Vercel, Netlify, Fastly, Google Cloud, Azure.
- Auth โ Auth0, Firebase Auth, Clerk, Supabase, AWS Cognito.
- Support โ Intercom, Zendesk, Crisp, Drift, Help Scout.
- AI providers โ OpenAI, Anthropic, Google Vertex, AWS Bedrock, Azure OpenAI, Replicate, Hugging Face, Perplexity, Cohere.
- Ecommerce and CRM โ Shopify, WooCommerce, HubSpot CRM, Salesforce.
- Embeds โ YouTube, Vimeo, Google Fonts, Google reCAPTCHA, Disqus, Calendly.
For each selected service, the generator produces a dedicated clause naming the service, the provider entity, the categories of data shared, the purpose, and a direct link to that provider's privacy policy. It also notes the cookies or local storage identifiers that service sets, which matters for your cookie disclosure section.
The New AI Disclosure Clauses
If your product uses an LLM, calls an AI API, makes automated decisions about users, or generates AI content that users see, your privacy policy needs clauses that didn't exist two years ago. The regulatory landscape is moving fast:
- EU AI Act (staged enforcement through 2026โ2027) โ requires disclosure of AI use, classifies AI systems by risk, and imposes transparency obligations on generative AI.
- GDPR Article 22 โ predates the AI Act but is the primary European lever against automated decision-making that produces "legal or similarly significant effects." If you use AI to approve loans, filter job applicants, or set prices, Art. 22 applies and users have the right to human review.
- Colorado AI Act (effective 2026) โ requires bias assessments and disclosure when AI is used in "consequential decisions" (employment, lending, housing, insurance, education, healthcare).
- NYC Local Law 144 โ requires bias audits for automated employment decision tools used on NYC residents.
- FTC enforcement โ under existing consumer protection law, the FTC has taken action against companies that make exaggerated AI claims or fail to disclose AI data use.
The generator produces four AI-specific sections when you enable AI disclosure:
- AI use disclosure โ what AI features your product has, what they do, what input data goes in.
- Data flows to AI providers โ specifically which providers receive what data. OpenAI, Anthropic, Google Vertex, AWS Bedrock, Azure OpenAI, etc. Each is its own third-party disclosure with specific retention and training-data policies.
- Training data disclosure โ whether you use customer data to train or fine-tune models, and how users can opt out.
- Automated decision-making rights โ if you make decisions about users based on AI output, the GDPR Art. 22 and state law rights users have to challenge those decisions.
Skipping these sections doesn't mean you're not subject to the rules. It means you're non-compliant with the rules while also not disclosing the non-compliance โ which is worse than disclosing accurately, because regulators can demonstrate you knew or should have known. If you use AI in any user-facing way, enable these clauses.
The Eight Industry Templates
Privacy policy requirements vary dramatically by business model. A content blog needs a much simpler policy than a fintech app. The generator offers 8 industry templates that pre-configure the data collection, third-party services, and required clauses typical for each:
- SaaS / Web Application โ accounts, billing, analytics. Presets: GA4, Stripe, Intercom, Auth0, AWS.
- Ecommerce โ checkout, shipping, orders, marketing. Presets: GA4, Stripe, Meta Pixel, Mailchimp, Shopify, Klaviyo.
- Mobile App โ device identifiers, location, in-app purchases. Presets: GA4, Firebase Auth, Apple Pay, Google Pay.
- Blog / Content Site โ lightweight analytics, newsletter signup, no accounts. Presets: GA4, Mailchimp, Cloudflare, Google Fonts.
- Agency / Professional Services โ lead capture, contact forms, CRM. Presets: GA4, HubSpot, Cloudflare, reCAPTCHA.
- Fintech โ payment, KYC, identity verification. Warning: GLBA, PCI-DSS, state money-transmitter laws all apply in addition to general privacy law. A generator is a starting point only.
- Health/Wellness (non-HIPAA) โ general wellness apps. Warning: if you handle Protected Health Information or are a Covered Entity under HIPAA, this template is NOT sufficient โ HIPAA requires a separate Notice of Privacy Practices and Business Associate Agreements.
- AI / ML Product โ LLM APIs, automated decisions, model training. Presets: GA4, OpenAI, Anthropic, Stripe, AWS. Includes all AI-specific clauses.
The templates aren't cages โ every preset can be customized. They're starting points that save you from missing obvious requirements (an ecommerce policy without a shipping data clause, a SaaS policy without billing disclosure, an AI product without training-data language).
Cookies, Tracking, and Consent
The cookies section of your privacy policy is where the most concrete disclosure happens โ specific cookie names, their purposes, their expiration times, and how users can opt out. Under GDPR and its ePrivacy interpretations, you generally need prior consent for non-essential cookies. Under CCPA, you need an opt-out mechanism and must honor GPC signals. These are different legal models and both apply if you serve both regions.
Four cookie categories the policy distinguishes:
- Strictly necessary โ session cookies, CSRF tokens, shopping cart state, auth tokens. Don't require consent under any major law.
- Functional โ language preference, theme, saved form state. Require consent under EU law.
- Analytics โ GA4
_ga, Mixpanelmp_*, PostHogph_*. Require consent under EU law. Cookieless alternatives (Plausible, Fathom) avoid the requirement. - Advertising / targeting โ Meta
_fbp, GoogleIDE, TikTok_ttp. Require prior explicit consent under GDPR. Under CCPA, trigger the right to opt out of sharing.
A complete policy lists the specific cookies you set, grouped by category, with expiration times. Attempting a generic "we use cookies for analytics and advertising" without specifics doesn't satisfy EU cookie-law requirements โ regulators have fined companies for this exact vagueness. The generator produces a per-service cookie table for every integration you've enabled.
Picking the Right Export Format
Once your policy is complete, the generator exports in six formats. Each has a specific use:
- HTML โ ready to host. The default. Drop the file at
/privacy/on your site, link from the footer of every page (required โ the policy must be accessible from every page where data is collected). - Markdown โ for documentation sites, GitHub repos, or CMSes that ingest markdown. Good for policies kept in version control alongside code.
- Plain text โ for email, legal review, or systems that can't render HTML. Strips all formatting; readability takes a hit.
- PDF โ via browser print dialog. Use for legal archives, counsel review, or users who ask for a downloadable version under their right of access.
- JSON โ machine-readable with metadata. Useful for building dashboards, internal tooling, or policy version control. Also the format the generator uses to save/load your configuration.
- Iframe embed โ paste into any page to render the current version live. Changes to your master policy propagate to every embed instantly.
The recommended workflow: export HTML to /privacy/ as your primary. Save the JSON configuration to version control or a password manager so you can re-generate after updates. Export Markdown if you keep docs in a CMS. PDF on demand for legal review. Don't embed in an iframe on your own site โ it's for third parties syndicating your policy (e.g., a product that white-labels its privacy doc from yours).
When You Need a Lawyer
A generator produces a competent starting point. It doesn't replace legal advice. The specific situations where you need an attorney, not a tool:
- Regulated industries. Healthcare (HIPAA โ Covered Entities, Business Associates), finance (GLBA, state money-transmitter laws), children's services (COPPA and state children's laws), insurance, credit reporting, background screening. Each has statute-specific disclosures a general generator can't fully produce.
- Complex data-sharing arrangements. Joint controllers under GDPR (two businesses jointly determining purposes), data processors with sub-processors, international transfers under SCCs without Data Privacy Framework coverage.
- M&A or major business changes. When company ownership changes, your privacy policy must disclose the transfer and users have specific rights that vary by jurisdiction.
- Litigation or regulatory investigation. If you've received a DPA inquiry, a CCPA request you can't easily satisfy, or a class-action demand letter, a lawyer is not optional.
- Novel data uses. Selling anonymized data to researchers, licensing data to advertisers, training third-party AI models on user content โ each has specific disclosure requirements evolving faster than templates can keep up with.
- High-risk processing. Biometric data at scale, public-space surveillance, credit scoring, employment decisions, large-scale children's data. All trigger Data Protection Impact Assessments under GDPR that the policy itself can't substitute for.
For a standard SaaS, ecommerce site, agency site, or content blog with commonly-used third-party services and no unusual data practices, a carefully configured generator output reviewed once by counsel is often sufficient. For anything listed above, the generator output is the starting material to bring to your lawyer, not a substitute for hiring one.
Why This Generator Runs in Your Browser
There's an ironic problem with most online privacy policy generators: to produce a policy about how your business handles user data, they ask you to send your business data to their server. Your company name, addresses, data practices, billing email, any AI disclosures about your own product โ all transmitted to, and often stored by, a third party whose privacy practices you haven't vetted.
The UDT generator does not do this. Every step runs in client-side JavaScript:
- The 10-step wizard runs locally.
- The jurisdictions, services, and industry template data is loaded with the page.
- The policy builder renders your output in the browser, live as you type.
- Auto-save uses localStorage (your browser's local database), not a server.
- Every export format (HTML, Markdown, text, PDF, JSON, iframe) generates client-side.
You can verify: open DevTools Network tab, interact with the generator, observe zero outbound requests beyond the initial page load. Disconnect from the internet after the page loads and the tool continues to work. Your business information โ including any sensitive details about your data practices โ never leaves your device. This is the correct default for any tool that handles business configuration data.
A Practical Workflow
The fastest path from "I need a privacy policy" to a hosted, compliant policy, using the generator as the engine:
- Step 1. Pick an industry template (SaaS, ecommerce, etc.) that matches your business. This pre-configures the likely data practices.
- Step 2. Audit your site with DevTools โ Network tab. List every third-party domain you send data to. Check those off in the Services step. Add any missing ones via the custom integration field.
- Step 3. Choose the jurisdictions based on where your users are (not where you are). GDPR for any EEA users. CCPA for any California users. Add others as applicable.
- Step 4. Fill in business info in Step 1: legal entity name, website URL, contact email, mailing address, governing law. These populate placeholders throughout the document.
- Step 5. Review the live preview. Check that every section reads accurately. Edit text directly for any business-specific nuance the templates don't capture.
- Step 6. Export HTML. Host at
/privacy/on your site. Link from the footer of every page โ this is a hard requirement. - Step 7. Save the JSON configuration to your password manager or version control so you can re-open and update when your stack changes.
- Step 8. Schedule a review: annually at minimum, and every time you add or remove a third-party service, expand into a new market, launch new features (especially AI features), or when relevant laws change.
Total time: 30โ60 minutes for a clean first version. Update cycle thereafter: 10โ15 minutes per change, because the generator remembers your config and only the deltas need rebuilding. The hidden cost of a privacy policy isn't writing it the first time โ it's keeping it accurate as your stack evolves. The generator exists to reduce that ongoing cost to something you'll actually do.
Frequently Asked Questions
Is a generated privacy policy legally binding?
Do I really need to disclose every third-party service?
How does this compare to Termly, TermsFeed, or iubenda?
Do I need a separate Terms of Service and Cookie Policy?
How often do I need to update my privacy policy?
Is it safe to type my business information into this tool?
Use the Privacy Policy Generator โ free, no signup required.
๐ก Open Privacy Policy Generator