Word Counter From URL

What this page does

You give it one webpage address. The server fetches the HTML, strips the parts that are not article content, and returns the remaining text to the counter. The browser then calculates the statistics and keyword list.

It is the URL-first version of a word counter. Use it when the text already exists online and you do not want to select and paste it by hand, or when you need a repeatable count for a page you are auditing.

Why count a URL instead of pasting

Copying a page by hand often drags in menus, cookie notices, image captions and related-post links. The fetch path removes common chrome elements before counting, so the result is closer to the article itself. It also gives you a consistent method for comparing several pages over time.

The trade-off is control. You cannot see exactly which block was removed, and a page with an unusual layout may lose a paragraph or keep a sidebar. For a one-off count of text you already have, pasting is more predictable.

What gets removed

The parser drops navigation, header, footer, aside, script, style, SVG and iframe elements before extracting body text. That removes most menus, banners, tracking code and embedded media. It does not apply the site's CSS, so text hidden by a stylesheet may still be counted if it is present in the HTML.

The server does not run the page's JavaScript. If the article is rendered client-side, the fetched HTML may contain a loading shell instead of the text. Pages behind a login, a paywall or a bot challenge may return an error or a blocking page.

The numbers you get

The counter reports words, characters with spaces, characters without spaces, sentences and paragraphs. Reading time uses 200 words per minute and speaking time uses 130, both rounded up. Average word length and the ten most frequent keywords are shown below the main cards.

Words are split on whitespace. Sentences end at a full stop, question mark or exclamation mark. Paragraphs need a blank line between them. Those rules are fast but crude for abbreviations, code samples and languages that do not use spaces.

Limits and accuracy

The fetch endpoint returns at most 200,000 characters. A very long page is truncated before counting, and the page does not warn you when that happens. The URL must start with http:// or https://, and only one address is submitted per run.

Because the server fetches a snapshot, the count can differ from what you see in a browser after scripts, ads and personalisation have loaded. Treat the result as an estimate of the server-delivered text, not a byte-for-byte audit of the rendered page.

Privacy

The URL is sent to the server and the fetched HTML passes through it. The counter does not create an account or keep a history of your URLs. Do not submit internal, private or authenticated pages to a public tool.

Step by step

1. Paste the full webpage address into the URL field.
2. Press Count Webpage and wait for the fetch to finish.
3. Read the word and character cards first.
4. Check the reading and speaking estimates.
5. Review the keyword list for accidental repetition.
6. Edit the page and repeat with the same URL to compare.

Counting different page types

A blog post or news article is the most reliable case. The main text sits in a predictable container, and the parser usually removes the menu, footer and sharing widgets. Author bios and related-post lists can survive, so a long article may count slightly high.

Documentation pages are messier. Code samples, command output and tables all count as words, and a page with a large code block can look much longer than its prose. Navigation sidebars may be removed, but inline warnings and version notes remain. Treat the number as a rough size signal, not a reading-length promise.

Product pages and landing pages are short by design. A count tells you little about quality there, because buttons, form labels and repeated calls to action inflate the total without adding readable content. Use the count for editorial pages and use character counts for metadata.

Using the count while editing

Run the same URL before and after a revision to see whether the edit added or removed substance. Because the fetch is a snapshot, a page that changes its layout between runs can produce a different count even when the article text is unchanged. Note the date and the URL when you compare numbers for a report.

Meta descriptions and social snippets are limited by characters, not words, so use the character cards for those. The keyword list is a frequency table: it can reveal accidental repetition, but it is not a difficulty score and it cannot tell you whether a phrase is worth ranking for.

Troubleshooting a failed fetch

A 403 or 404 usually means the page blocks automated requests or the address is wrong. A bot challenge, a paywall or a login wall can return a blocking page instead of the article. Client-rendered sites may return a shell with no text because the server does not run JavaScript.

Check that the URL includes http:// or https://, remove tracking parameters, and try the canonical address without a fragment. If the fetch still fails, paste the article text into a standard word counter instead; that bypasses the network and gives you full control over what is counted.

Reading estimates and page length

The 200 words per minute figure is a planning average for adult readers. A technical page with tables and code takes longer; a simple announcement takes less. Treat the estimate as a scheduling aid, not a promise about every reader.

A 1,000-word article lands near five minutes, a 2,000-word guide near ten, and speaking time runs faster because 130 words per minute is a slower delivery. The count does not measure comprehension, so a dense page can take far longer than the clock suggests.

Repeat the count after a revision to confirm the change.

Frequently Asked Questions