# How to add a privacy policy and terms to a React app > Add privacy policy and terms pages to a React app with real public routes, correct generated documents, footer links, and production refresh checks. Published 2026-11-03 by Jitoma Solutions s.r.o. ยท 6 min read Add privacy and terms to a React app as two reviewed documents with public destinations, clear links, and routes that work when opened directly. Start by checking whether the app uses a framework, a client router, or static files. A component that displays after an in-app click is only part of the job; users must also be able to follow the saved URL later. Canonical URL: https://legalpolicygenerator.com/blog/how-to-add-privacy-policy-and-terms-to-a-react-app ## Key takeaways - Use separate reviewed privacy and terms documents with clear public destinations. - Inspect the existing router and production host before assuming nested routes will work. - Test refresh, anonymous access, form return behavior, and keyboard navigation. - Preserve generated content during future AI-assisted layout edits. ## Decide what each document needs to explain Privacy describes what happens to personal information. Terms describe the service relationship, including account rules, payments, content, and access where relevant. They can share operator and product facts while requiring different answers. Do not make a single page labelled Legal and assume its existence answers both questions. Review [privacy policy versus terms](https://legalpolicygenerator.com/blog/privacy-policy-vs-terms-and-conditions) before collecting inputs. Then inventory authentication, forms, storage, analytics, billing, uploads, and support. For terms, separately decide the operational rules you can enforce. A coding assistant can locate implementation details, but the operator must confirm business choices. Generate each document from those facts rather than asking for a generic React boilerplate policy. ## Identify the app's actual routing and rendering model React projects can use different frameworks and routers, so inspect the current entry points and dependencies. Locate existing page routes, the shared navigation, error handling, and authentication checks. If the project already has a legal layout, reuse its reading structure instead of adding a second competing page system. For a Next.js project, use [the Next.js privacy page guide](https://legalpolicygenerator.com/blog/how-to-add-a-privacy-policy-to-a-nextjs-app). For a client application, inspect the host's behavior on a direct request to a nested path. The development server may handle paths differently from production. Avoid introducing a router solely to publish one document when an existing static-page or hosted-link arrangement fits the product more simply. ## Generate two documents and review the overlap Complete the [Privacy Policy Generator](https://legalpolicygenerator.com/privacy-policy-generator) and [Terms of Service Generator](https://legalpolicygenerator.com/terms-of-service-generator) separately. Check names, contact information, product scope, account behavior, payment flow, and deletion statements across the previews. The documents serve different purposes, but they should not contradict each other about how the same product works. For example, closing an account and cancelling billing may require coordinated implementation. If terms promise one outcome while privacy describes another, investigate the product rather than editing words to hide the mismatch. Confirm the exact price and delivery options for each set of answers. Save the approved output and inputs so an interface redesign does not erase the basis of your review. ## Choose local pages or stable external destinations Two ordinary local routes can fit an application that already serves public content. Hosted document URLs can be simpler when the entire app is behind authentication or the team does not want to maintain local document pages. Standalone HTML files also work when your deployment serves static assets at stable public addresses. Choose deliberately and maintain one clear destination for each document. A PDF can accompany a page, but readers should not need a download to find basic information on a phone. If using a supported HTML fragment, preserve its structure and scoped styles inside the app shell. Do not replace full document sections with shortened JSX text because the generated markup looks lengthy. ## Handle direct links and browser refresh correctly Open each proposed legal URL directly in a new private window. Reload the page and check both the response and the rendered result. A client router can recognize a route after the app starts while the production host returns an error for the same address. Another failure is a catch-all response that displays the homepage instead of the document. Check route resolution, redirects, status, and visible heading together. If your deployment needs a fallback or a static-file mapping, configure it for the current stack and verify other pages still behave correctly. Do not expose private application routes while exempting legal pages from login. The goal is narrow, intentional public access to the reviewed documents. ## Add links where decisions happen Put Privacy Policy and Terms of Service in the shared footer with clear labels. Then inspect registration and checkout separately. People need access to privacy information before providing data, while the presentation of terms needs to fit the action creating the service relationship. A footer is a return location, not a complete design for every transaction. See [terms placement on a website](https://legalpolicygenerator.com/blog/where-to-put-terms-and-conditions-on-a-website) for that distinction. Check portals and third-party hosted screens that do not render your React footer. Add a settings or account location inside the signed-in app as well. Use real links, preserve form progress when someone reads them, and avoid making legal access depend on an unchecked JavaScript event handler. ## Verify reading, focus, and the small-screen layout Use one main heading for each document and preserve the generated section headings, lists, and links. Keep paragraphs readable rather than stretching prose across a desktop monitor. Test narrow widths, text zoom, keyboard navigation, and print output. Long contact addresses and provider links should wrap without forcing horizontal scrolling. Open the document from a partially completed registration form and return to check whether the user loses their input. Make link focus visible and avoid a modal that traps readers in a scrolling panel. The [privacy link placement guide](https://legalpolicygenerator.com/blog/where-to-put-a-privacy-policy-link) discusses accessible labels and locations. Test the production bundle as well as development, since omitted assets or route settings can change the experience. ## Protect the document during later AI edits Tell your coding assistant which generated document is approved and where it is stored or hosted. Ask it to preserve the exact legal content while making layout changes. If an update requires new processing or service terms, return to the factual questionnaire and review a new version rather than improvising paragraphs inside a styling task. Check both destinations after any navigation, authentication, or deployment refactor. Include the legal links in the launch checklist alongside signup and payment. Our [policy update guide](https://legalpolicygenerator.com/blog/how-often-should-you-update-your-privacy-policy) explains content review triggers. Working legal routes are maintained product surfaces: they need stable destinations, readable output, and a clear owner after the initial app generation session. ## Common questions ### Can I use one route for both privacy and terms? You can create a legal index that links to both, but each complete document should have a clear destination and heading. Avoid making users search a long combined page to identify which rules apply. Separate destinations are also easier to reuse in signup, checkout, and platform settings. ### Why do my legal links work locally but fail after deployment? The host may handle direct requests differently from your development server or client router. Test each address by opening and refreshing it directly on production. Inspect redirects, status, and the displayed document rather than assuming that successful in-app navigation proves the route is independently reachable. ### Do I have to render the policy inside React? No. A hosted public document or self-contained HTML file can be a suitable destination. Choose an approach that fits your deployment and can be maintained. If you integrate a fragment into React, use the reviewed output and retain all substantive sections rather than rebuilding a shortened version. ### Can the assistant write the legal copy while adding routes? Use the document generator for the actual privacy and terms wording, then have the assistant integrate the reviewed result. The assistant can inspect code and collect factual inputs, but it should confirm business decisions and preserve the approved content during page construction and future styling work. ## Official sources - [React documentation: creating a React app](https://react.dev/learn/creating-a-react-app) - [W3C Web Accessibility Initiative: Easy Checks](https://www.w3.org/WAI/test-evaluate/easy-checks/) Generated wording reflects supplied facts. It is not legal advice or a guarantee of compliance or enforceability.