Verant · Verified, not guessed

How to proofread a JavaScript-rendered (SPA) website

On a single-page app, the words a visitor reads are assembled by JavaScript in the browser, not sent in the initial HTML. That breaks the tools that read raw source — and it is exactly why a proofreader has to read the rendered page. Here is what goes wrong, and how to check the copy that actually shows up.

Last reviewed: 2026-06-21

To proofread a JavaScript-rendered (SPA) website, you have to check the page after the JavaScript runs and builds the content — not the raw HTML the server first sends. On a React, Vue, Svelte, Angular, or similar single-page app, "View source" and static spell checkers read a near-empty shell, so they miss almost all the copy. Open the rendered page in a browser (or use a tool that renders it) and proofread the text you actually see.

Verant does this by default: it loads each page in a headless browser, waits for the content to render, and then proofreads the visible copy for the same six kinds of issue it checks on any site — grammar, spelling, punctuation, style, clarity, and leftover placeholder text. Because it reads the rendered DOM, client-side copy gets checked the same as server-rendered copy.

Why static checkers miss a single-page app

A single-page app ships a small HTML shell — often little more than an empty `<div id="root">` and a script tag — and then JavaScript fetches data and builds the visible page in the browser. So the headline, the body copy, the nav, and the footer you read were never in the HTML the server sent; the framework rendered them client-side after load.

Anything that reads the raw source sees the shell, not the result. "View source", a curl request, and most static spell checkers and crawlers read the bytes the server returned and stop there, so they check almost none of your actual copy — and report a clean page because there was barely any text to flag. The errors are all in the rendered output they never executed the JavaScript to produce.

Proofread the rendered page, not the source

The fix is to check the page the way a visitor experiences it: after the framework has run and the copy is on screen. By hand, that means opening the live page in a real browser and reading the rendered text — or using your browser's "Inspect" view (the live DOM), not "View source" (the original HTML), since only the former reflects what JavaScript built.

Verant renders every page in a headless browser before it proofreads — it waits for the content to load and scrolls the page so lazy-loaded and below-the-fold sections render too, then reads the visible copy from the live DOM. That is the same path it uses for a server-rendered site, so a React or Vue page is proofread exactly like a static one: the six kinds of copy issue, with your exact text quoted on every flag.

What this is — and is not

This is a copy check on rendered content. Verant reads the text a JavaScript app builds and proofreads it for the six kinds — grammar, spelling, punctuation, style, clarity, and leftover placeholder copy. The SPA angle is only about where the words come from (built client-side), not a different kind of checking: the copy pass is the same.

It is not a JavaScript audit. Verant does not test your bundle, your runtime errors, your hydration, your performance, or your SEO — whether a crawler can render your app for indexing, your Core Web Vitals, and your meta tags are separate concerns with their own tools. It also does not check broken links, facts, or accessibility. It renders the page so it can read the copy; the copy is all it judges.

Proofread a JavaScript-rendered site, step by step

  1. 1

    Confirm your site is client-rendered: open a page, choose "View source", and if the copy you see on screen is missing from the raw HTML, the JavaScript is building it after load.

  2. 2

    Stop checking the source. Read the rendered page instead — open the live URL in a browser and proofread the text on screen, or use your browser's "Inspect" (the live DOM) rather than "View source".

  3. 3

    For more than a page or two, use a tool that renders the page before reading it: paste your URL into Verant, which loads each page in a headless browser, waits for the content, and proofreads the rendered copy.

  4. 4

    Review the flagged corrections in context — Verant quotes your exact text on every flag and verifies each fix with a second AI agent — across the six kinds: grammar, spelling, punctuation, style, clarity, and placeholder copy.

  5. 5

    Run the separate, non-copy checks with their own tools — render-for-indexing/SEO, performance, links, accessibility — then fix the copy in your code or CMS and re-scan to confirm.

How verification works

Most proofreading agents show you every suggestion and make you sort the good from the bad. Verant runs an adversarial second pass — Claude Sonnet proofreads, then GPT-5 tries to break each correction. What survives is what we show you. Verbatim is sacred: every flag quotes your exact text; we never auto-apply fixes.

Keep going

Related reading: grammar of the rendered live site, website proofreading software, and pre-launch proofreading checklist.

Frequently asked questions

Why does a spell checker miss copy on a React or Vue site?

Because a single-page app sends a near-empty HTML shell and builds the visible copy with JavaScript after the page loads. A checker that reads the raw source sees the shell, not the rendered text, so it checks almost none of your actual copy. You have to proofread the page after the JavaScript runs.

How does Verant read client-rendered content?

It loads each page in a headless browser, waits for the content to render, and scrolls the page so lazy-loaded sections appear, then reads the visible copy from the live DOM. So a client-rendered React, Vue, or Svelte page is proofread the same way as a server-rendered one.

Does Verant audit my JavaScript, performance, or SEO?

No. It renders the page only so it can read the copy, then proofreads that copy for the six kinds — grammar, spelling, punctuation, style, clarity, and placeholder text. It does not test your bundle, runtime, hydration, performance, or whether search engines can render your app — those are separate checks with their own tools.

What is the difference between "View source" and the rendered page?

"View source" shows the raw HTML the server first sent — on a single-page app that is mostly an empty shell. The rendered page is what JavaScript built in the browser afterward, which is what visitors actually read. Proofreading has to use the rendered page; your browser's "Inspect" view shows it.

Try it on your site →