Last updated:
Character Count Design for Terms of Service and Privacy Policies - Balancing Legal Requirements with Readability
Terms of service and privacy policies are legal contracts between service providers and users. Yet their character counts continue to balloon year after year, and it is not unusual for a major service's terms to run long enough that simply reading the full text takes tens of minutes. Designing documents that maintain legal comprehensiveness while staying within a character count users will actually read is a challenge requiring collaboration between legal and UX teams. This article presents practical approaches to character count design grounded in domestic and international legal requirements.
Terms of Service for Major Services - Length Comes Down to How Documents Are Bundled
Line up the terms of service of large platforms and the lengths scatter from a few thousand characters to tens of thousands. What produces that spread, however, is not company size or industry but an editorial decision: how many separate documents the conditions are split across. Terms are also reissued with every revision, so comparing another company's character count as a number leaves you working from a premise that collapses within months. What is worth borrowing for your own design is not the figure but the choice between the following two structures.
- Separated model: Keep the base terms that apply to every service short, and carve out service-specific conditions into a separate "additional terms" document. Google's terms of service follow this model, so reading the common part alone conveys the overall framework, and users only need to follow the additions for the services they actually use
- Consolidated model: Gather the conditions for multiple services into a single document. Apple's media services terms follow this model, covering the App Store, Apple Music, and other services in one text, which makes that single document long. Nothing has to be looked up elsewhere, but readers are expected to skip past the sections that do not apply to them
The separated model holds down the character count of any one document, but it complicates the cross-references between documents and creates a different readability problem: no one can tell where a given rule is written. Judged on character count alone the separated model always looks better, yet the total volume the user ultimately reads is unchanged. This is easy to confuse with the layered approach discussed later: the layered approach divides the same content by level of detail, whereas splitting off additional terms divides the content itself by which service it governs.
To find out whether your own terms fit within a readable length, measure the published full text as a character count and convert it into a reading time at the reading speed of your expected audience. Starting from your own measurement is faster to act on than hunting for figures other companies have published.
Why Terms of Service Keep Growing - Structural Factors
Several legal and business structural factors drive the inflation of terms of service character counts.
- Legal risk avoidance: Lawyers operate on the principle that "what isn't written isn't agreed upon," attempting to cover every risk scenario. This results in detailed descriptions of even low-probability events, inflating character counts
- Regulatory complexity: The number of applicable regulations keeps growing - GDPR, Japan's Act on the Protection of Personal Information, the Telecommunications Business Act, the Specified Commercial Transactions Act, and more. Disclosing everything each regulation requires inevitably increases character counts
- Feature expansion: Single platforms now offer payments, messaging, content distribution, advertising, and more, each requiring its own usage conditions
- Litigation response: Repeated "patch-style revisions" that add clauses addressing past litigation issues cause documents to bloat
- International expansion: Supporting multiple jurisdictions (Japan, EU, US, etc.) requires adding jurisdiction-specific provisions
These factors interact to continuously push character counts upward. Yet as character counts increase, user read-through rates decline, normalizing the state of "agreed but unread." The layered approach introduced next addresses this contradiction.
The Layered Approach - A Practical Solution to the Character Count Problem
The layered approach divides legal documents into multiple tiers, providing information progressively based on user interest level. No provision of the GDPR specifies how many layers to use or how long each may be. Recital 58 does, however, require as a matter of the transparency principle that information addressed to the public or to the data subject be "concise, easily accessible and easy to understand," using "clear and plain language and, additionally, where appropriate, visualisation." Dividing a document into layers has become the standard practical technique for satisfying that requirement and comprehensiveness at the same time.
| Layer | Name | Recommended Chars | Content | Display Method |
|---|---|---|---|---|
| Layer 1 | Summary | 500-1,000 chars | Plain-language summary of key provisions | Displayed directly on consent screen |
| Layer 2 | Overview | 2,000-5,000 chars | Bullet-point highlights of each section | Expandable accordion UI |
| Layer 3 | Full Text | 10,000-30,000 chars | Legally complete full terms | Link to separate page |
The Layer 1 summary is not a legally binding document but supplementary material to aid user understanding. Adding a note like "This summary is for reference only; only the full text has legal effect" mitigates legal risk while improving readability.
This approach is essentially the same as the structure in business email character count design - "convey the key point in the subject line, supplement with details in the body." User attention is finite, and designs that present the most important information first are essential.
GDPR Character Count-Related Requirements
The GDPR (General Data Protection Regulation) sets specific requirements for how privacy policies should be written. While no article directly regulates character counts, the following principles indirectly affect character count design.
| GDPR Article | Requirement | Impact on Character Count |
|---|---|---|
| Art. 12(1) | Provide information in a concise, transparent, intelligible, and easily accessible form | Requires avoiding verbose legal language and writing in plain terms |
| Art. 12(1) | Use clear and plain language, especially for information addressed to children | Requires minimizing jargon and adding explanations |
| Art. 13 | Disclose controller identity, processing purposes, legal basis, retention periods, data subject rights, etc. | Many required disclosures necessitate a certain character count |
| Art. 14 | Provide information about personal data not obtained directly from the data subject | Additional explanation needed when third-party data acquisition exists |
| Recital 39 | Enable natural persons to be aware of collection, use, consultation, and processing of personal data | Technical processing must be explained in non-technical language |
GDPR's requirements for "concise and intelligible" and "disclose all necessary information" are inherently contradictory. Trying to satisfy both in a single document means that choosing concision produces gaps in disclosure, while choosing comprehensiveness produces a length nobody reads. Layered design took hold in practice because it resolves the contradiction on the side of document structure. Provide a concise summary in Layer 1 and the legally complete full text in Layer 3, and neither requirement has to be dropped.
Japan's Personal Information Protection Act and Privacy Policy Character Counts
Japan's Act on the Protection of Personal Information (as in force in 2026, reflecting the amendment that took full effect in April 2022) doesn't prescribe writing methods as specifically as GDPR, but the matters that must be written are clearly set out in its provisions. The following organises them by article number and article heading.
- Specifying the purpose of use (Art. 17): Specify the purpose of use as precisely as possible. Vague descriptions like "used for marketing" are insufficient - specifics like "used for product recommendation displays" are required
- Notice of the purpose of use upon acquisition (Art. 21): Once personal information has been acquired, notify the individual of the purpose of use or make it public. Publishing it in a privacy policy is the common way of discharging this obligation
- Restriction on provision to third parties (Art. 27): Provision to a third party requires the individual's consent as a rule. Where the opt-out route is used to provide data without prior consent, the data items and the means of provision must be placed in a state where the individual can know them, and a notification must be filed with the Personal Information Protection Commission
- Publication of matters concerning retained personal data (Art. 32): Place in a state where the individual can know them the operator's name or corporate name, address and the name of its representative, the purpose of use of all retained personal data, and the procedures for responding to disclosure requests
- Security control measures (Art. 23): Take the measures necessary and appropriate to prevent leakage of personal data. The basis for making the substance of those measures knowable is not Article 23 itself; it comes from the cabinet order issued under Article 32, paragraph 1, item 4
Getting the mapping between article numbers and obligations wrong distorts where items are placed in the policy and even how the headings are drawn up. In particular, the fact that the basis for "writing out the substance of the security control measures" sits on the Article 32 side rather than in Article 23 is a pitfall that is easily confused in practice.
Writing all of these items out without omissions puts a privacy policy in the range of several thousand characters. This article treats 3,000-5,000 characters for the mandatory items alone, and 8,000-15,000 characters once web service-specific items such as cookie usage, analytics tools, and ad delivery service integrations are added, as design guidelines. These are not statistics from measured samples; they are built up from the structural template presented below.
Writing Techniques for Improving Readability
Improving legal document readability requires not just reducing character counts but refining document structure and expression. Many techniques used in press release character count design apply to legal documents as well.
| Technique | Before | After | Character Change |
|---|---|---|---|
| Active voice conversion | "Your personal information is collected by us" | "We collect your personal information" | Shorter and clearer |
| Eliminating double negatives | "We are not without responsibility" | "We are responsible" | Significantly shorter |
| Using bullet points | "We collect name, address, phone number, email address, and date of birth" | "We collect: Name / Address / Phone / Email / Date of birth" | Greatly improved readability |
| Consolidating definitions | Repeating "The Service means..." in each clause | Define once in a definitions section, then reference "the Service" | Eliminates repetition |
| Specific headings | "Article 5 (Miscellaneous)" | "Article 5 (Data Retention and Deletion)" | Content clear from heading alone |
Legal-specific expressions like "shall," "including but not limited to," and "notwithstanding the foregoing" are sometimes necessary for legal precision, but overuse severely degrades readability. Working with legal teams to identify clauses that can be rewritten in plain language and improving them incrementally is the realistic approach.
Privacy Policy Structure Template
Here's an effective privacy policy structure with recommended character counts.
| Section | Recommended Chars | Content | Priority |
|---|---|---|---|
| Introduction | 200-400 chars | Policy purpose, scope, last updated date | Required |
| Information We Collect | 500-1,000 chars | Types of data collected, collection methods | Required |
| Purpose of Use | 300-800 chars | Specific purposes for each data type | Required |
| Third-Party Sharing | 300-600 chars | Recipients, shared data, legal basis | Required |
| Data Retention and Deletion | 200-400 chars | Retention periods, deletion criteria and methods | Required |
| User Rights | 300-600 chars | How to request disclosure, correction, deletion, suspension | Required |
| Cookies and Tracking | 300-600 chars | Technologies used, opt-out methods | Required for web services |
| Security Measures | 200-400 chars | Technical and organizational data protection measures | Required |
| Children's Privacy | 100-300 chars | Age restrictions, parental consent | Required for applicable services |
| Policy Changes | 100-200 chars | Notification method for changes, effective date | Required |
| Contact | 100-200 chars | Data protection officer contact information | Required |
Following this template yields a total privacy policy of approximately 2,600-5,500 characters. Compared to optimal blog post length, this is roughly the length of a single blog article. At this range, it's realistic for users to read the entire document.
Terms of Service UI Design and Character Count
Character count design for terms of service is closely tied not just to document content but also to the UI that displays it. The same 10,000-character terms can yield vastly different read-through rates depending on presentation.
- Scrollable text box: A small text box embedded in the consent screen requiring scrolling. The viewport is narrow, so little fits on one screen and following the full text takes dozens of scroll actions. It is the costliest format to read through, and where the consent button is clickable from the outset it goes essentially unread
- Accordion UI: Collapsible sections users can expand selectively. Because the list of headings is visible first, users can open the sections that concern them. The flip side is that a collapsed section reads as "something you need not read," so key provisions left closed by default are consented to without being opened
- Step format: Terms split into multiple steps showing 1-2 sections each. Holding each screen to 500-1,000 characters makes it a unit a reader can finish, but drop-off part-way through grows as the number of steps rises, so the split count and the volume per screen trade off against each other
- Highlights + full text link: Key provisions (data usage purposes, third-party sharing, cancellation terms) displayed with highlights, full text available via link. This narrows the range you want read, but the choice of what to highlight is itself the provider's discretion, and leaving out unfavourable clauses undermines transparency
In practice, combining the step format with highlights is the easiest option to work with. Show a 500-1,000 character summary at each step and provide a link to the full text for users who want the detail. Whichever method is used, if the consent button can be pressed from the very start, none of the document design shows up in the outcome. It is safer to assume that UI refinements reach only as far as lowering the burden on users who already have a reason to read.
Multilingual Legal Documents and Character Count Variation
Global services need to provide terms of service in multiple languages. The same content runs to different character counts depending on the language, and that gap affects layout and UI design. The direction of the variation can be explained from the properties of the languages themselves.
- Information carried per character differs: In Japanese and Chinese a single Chinese character carries a word stem, so the same content can be written in fewer characters. Languages written only in phonetic scripts need several characters per word, and the count rises accordingly
- Whether words are separated by spaces: English, German, French and similar languages count the spaces between words as characters, so even at the same word count the spaces add to the total. Because the result changes depending on whether spaces are included, the counting basis has to be stated up front as a premise for any comparison
- Handling of compound words and function words: German joins several words into one, so a text can look short measured in words while individual words become very long. French has many constructions in which articles and prepositions cannot be dropped, which tends to make it longer than English
- Writing direction: Arabic and Hebrew are written right to left, so quite apart from any change in character count, the UI layout itself has to be mirrored
Actual ratios move with how the source text is written and with the translator's approach, so rather than estimating them in advance it is more reliable to measure once even one language's translation is finished and use that as your baseline. When designing the Layer 1 summary of the layered approach, base the layout on the language with the highest character count and adjust the others in the direction of leaving extra whitespace. Fixing the frame around the Japanese version instead will cause text to overflow in many of the other language versions.
Update Frequency and Character Count Trends
Terms of service aren't created once and forgotten - they're regularly updated for legal amendments, feature additions, and litigation responses. With each update, clauses are added and character counts trend upward.
The triggers for an update fall broadly into two groups. One is circumstances on the service side (features added, offerings discontinued, pricing changed), where only the relevant clauses are replaced. The other is circumstances on the legal side: when an amendment to the Act on the Protection of Personal Information or a cross-cutting regulation such as the EU's Digital Services Act moves, the items that must be disclosed change, so a revision becomes necessary even when nothing about your own service has changed. Because the latter causes many operators to revise at the same time, scanning other companies' revision histories reveals clusters around the dates when the law moved.
To curb character count growth, it's important to "consolidate" alongside "additions" during updates. Specifically, these approaches are effective:
- Merging duplicate clauses: Consolidate similar clauses added through past revisions to eliminate redundancy
- Removing discontinued service clauses: Delete clauses for services no longer offered
- Separating into additional documents: Extract service-specific conditions into supplementary terms to keep the base terms concise
- Reviewing definitions: Clean up the definitions section and remove unused defined terms
Measuring Read-Through Rates
Improving terms of service character count design starts with measuring current read-through rates. For web service terms pages, the following metrics can be tracked.
| Metric | Measurement Method | Benchmark |
|---|---|---|
| Time on page | Analytics tools | Read it as a ratio against the estimated time needed to finish the full text, not as a raw number of seconds |
| Scroll depth | Scroll event tracking | Share of users who reach the area near the end (set the threshold to suit how the document is structured) |
| Accordion expansion rate | Click event tracking | Compare expansion rates to identify high-interest sections |
| Time to consent | Consent button click time - page load time | Under 3 seconds suggests "agreed without reading" |
| Bounce rate | Analytics tools | High bounce from terms page suggests character count is a barrier |
If the vast majority of users consent in under 3 seconds, it means the terms are effectively unread. In this case, UI-level improvements like introducing the layered approach or highlighting key provisions are needed. The fundamental solution isn't just reducing character counts but transforming the structure into something users want to read.