The Terms Panel That Only Exists After JavaScript: Six Quick Answers, a Print Control and a Support Prompt

I work on OnePassApps, the team behind app.onepassapps.com. This post is about one page of our own site, and about the part of it that only exists once JavaScript has run. I measured it on 10 November 2026: first the served HTML, from outside the browser with a plain HTTPS request, and then the rendered page in a real browser, signed out.

The split

Our terms page, at app.onepassapps.com/terms, is served as 74,466 bytes of HTML. Nearly all of it is the terms themselves: strip the markup and the served response still carries 30,609 characters of text, and that text holds the whole document - ten numbered sections, the version stamp "Effective 21 October 2026 · Version 2026-10-21", the refund policy, the model cancellation form, the merchant-of-record paragraph and every clause in between.

The panel around it is different. In the served HTML there is no "Quick answers", no "Print or save these terms", no "Contact support" and no "Questions?" prompt - not one of those 10 strings appears anywhere in the 74,466 served bytes. All of it appears only in the rendered page, which I read in the visible browser: a "Quick answers" heading above six entries - Cancel a plan or ask for a refund, How your information is used, Your privacy rights, Delete your account, Report a copyright concern, Who to contact - together with a print control and a "Questions?" prompt beside a "Contact support" button.

So the terms themselves are readable without JavaScript, and the way in to them is not.

The contents list does not use the section headings

One detail that only shows up in the rendered page. The contents list names each section by a short label - Accounts, The service, Acceptable use, Content and rights, Plans and payments, Privacy and storage, Privacy rights, Liability, Ending use, Law and contact - and under "Content and rights" it carries two nested entries, "NewsFlow sources" and "Movie catalogue sources".

The heading inside the document is not that label. The first section is headed "Agreement and accounts", while the contents entry beside it reads "Accounts". The contents list is a short name for a section, not its title, and reading one for the other is an easy way to misdescribe the document.

Why the split is worth knowing

A crawler, a text-mode browser or an API client that reads the served HTML gets the terms in full and none of the navigation. A person in a browser gets both. The part worth naming is which half carries the commitments: the document's own rules - the refund window, the cancellation right, the deletion and backup language - are all in the served half, so nothing we promise is hidden behind a script. What is behind the script is the door.

The print control is the one piece of this panel we have written about elsewhere, on the print layer of our own site. This post is about the other half of it: the six quick answers and the support prompt, and the fact that none of the panel is in the bytes we serve.

What this measurement does not cover

One build, one day, one network. The served side is one plain HTTPS request for one URL, and the rendered side is one read of the same URL in a visible browser, signed out, with no cookies. The two numbers are not like for like and I am not comparing them as if they were: 74,466 is bytes of markup and 30,609 is characters of text left after stripping the tags out of it. I did not press the print control, the support button or any quick answer, I did not test the print stylesheet, and I did not check what a reader sees with JavaScript disabled beyond what the served response proves. I am not making a claim about any other page on the site, and I did not read the served panel of any other route.

Try it yourself

The full document, all ten sections, is on the OnePassApps terms of use page. Every app and studio has a plain-language guide with its limits and its tool list: the OnePassApps guides.