What a template can and cannot do for you
A generated privacy policy is a checklist made of prose. Its real value is structural: it makes sure you have said something about what you collect, why, who you share it with, how long you keep it, what rights users have, and how to contact you. Those are the sections a reviewer expects to find, and a blank page is where most people forget half of them.
What it cannot do is know your business. It does not know that your analytics vendor stores data in a particular region, that you retain order records for seven years for tax reasons, or that your sector has its own reporting duty. Those are the parts that make a policy accurate rather than merely present.
So the honest framing is that this gets you from nothing to a reviewable draft in about ninety seconds, and the review still has to happen. The document says exactly that, in its own first section and again in its last, so the warning cannot be lost when the text is copied elsewhere.
Filling in the questionnaire
- Type your Company / website name and a Contact email for privacy questions. Leave either blank and a bracketed placeholder is used instead.
- Pick a Site type. The four options are General website, Blog, Online store (e-commerce) and Web app / SaaS. This changes how the document refers to your service throughout.
- Pick a Jurisdiction. General / US baseline only, GDPR (European Union / UK), CCPA (California), or Both GDPR and CCPA.
- Under Data you collect, tick the boxes that are true. Cookies / tracking technologies, Analytics (e.g. Google Analytics), Third-party ads (e.g. Google AdSense), Contact form / email sign-up, User accounts / registration and Payments / online purchases.
- Choose an Export format of HTML, Markdown or Plain text.
- Read the draft in the output box, which regenerates as you change any answer.
- Use Copy for the clipboard, or the download button, which is labelled with the filename it will produce.
Tick honestly rather than defensively. A policy claiming you collect payment information when you do not is a promise you have to keep, and a policy that omits your ad network is the kind of gap that gets noticed.
Which sections your answers switch on
The document is not one fixed block of text with names substituted. It is assembled from a list of sections, some of which only exist if you asked for them.
The cookies checkbox adds a dedicated tracking technologies section and also adds a line to the list of information collected. The advertising checkbox adds a section about third-party ad networks. The jurisdiction dropdown is the biggest lever: choosing GDPR appends a section covering European rights, choosing CCPA appends the California one, and choosing both appends both, in that order.
Everything else is unconditional, because everybody needs it: an introduction with the effective date, what is collected, how it is used, who it is shared with, how long it is kept, a baseline rights section, children’s privacy, how changes are announced, and how to get in touch.
Three formats that cannot drift apart
The policy is built once as an ordered array of headings and paragraphs. Each export format is then a small independent serializer over that same array.
That structure is the reason the three outputs can never disagree. Nobody is maintaining three parallel copies of the text, so a section added for one format automatically exists in all three. The plain text version numbers its sections and separates paragraphs with blank lines, the Markdown version uses headings, and the HTML version escapes anything you typed before writing it into markup, so an ampersand in your company name cannot break the page.
Pick HTML if it is going straight into a website, Markdown if it lives in a repository alongside your docs, and plain text if you are pasting it into an email or an app store form.
The rest of the launch checklist
A policy is one of several files a site needs before it goes live. Robots.txt Generator covers what crawlers may fetch, and Meta Tags Generator produces the title, description and social preview tags for each page.
If your policy mentions email, the sending side needs its own records: Email DNS Generator builds the SPF, DKIM and DMARC entries that keep those messages out of spam folders. For server-level redirects, security headers and caching rules, Nginx and .htaccess Config Generator writes the configuration block. And when somebody asks for a signed paper copy of the policy, TXT to PDF turns the plain text export into a document. The rest is on the dev tools hub.
