Keyword Density Checker Free Tool

Enter a URL

About Keyword Density Checker

What This Tool Actually Does

The Keyword Density Checker on limitlessreferrals.info is a server-side word frequency counter that starts with a URL and ends with a sorted table of single words. You paste a web address into the single input field, press Submit, and the tool fetches that page, converts the HTML to plain text, splits the text into tokens, and counts how often each token appears. The output is a table that shows every distinct word that survived the filtering rules, along with its raw count and its percentage of the total.

The tool makes one request to this site, the POST that carries your URL to the results page. The actual page fetch happens on the server side. The tool never sees the page as your browser renders it. It sees the raw HTML that a server delivers to a plain HTTP client, which means anything your browser would build with JavaScript simply doesn't exist for this checker.

The whole process runs through a small pipeline. First the input is trimmed, lowercased, and stripped of its scheme. If you type example.com, the tool prepends http:// and fetches that. If you type https://example.com, the scheme is removed and plain http:// is added anyway. The fetch uses a Chrome 87 user agent, follows redirects, and gives up after thirty seconds. No JavaScript is executed during the fetch.

Once the HTML arrives, an html2text converter removes the head, script, and style blocks, then strips all remaining tags. The text that remains is lowercased and split on single spaces. Each token must be longer than three characters to survive. Tokens must also avoid a tiny stop list of nine words and must not contain http or mailto:. Punctuation is not stripped at this stage, so read. and read are different tokens, and crawler, differs from crawler.

The counts are then sorted in descending order. Each token's percentage is its count divided by the total number of kept tokens, multiplied by one hundred, and rounded to two decimal places. A second filter then removes any token that contains a digit or any of a long list of punctuation characters, so words with punctuation glued to them vanish from the displayed table. Their counts still sit in the denominator, which is a quirk you should understand before you interpret any percentage.

The live test run for this rewrite fetched two pages. The first was example.com, which produced eight keywords, each with a count of one and a percentage of ten. The eight tokens were example, domainthis, domain, documentation, examples, without, avoid, and more. The second was the Wikipedia article on Web crawlers, which produced a large table of distinct tokens, with crawler at the top.

The tool's behavior is largely explained by that Wikipedia result. The top rows were crawler, search, that, pages, from, and with, in descending order of count. The word that is a function word with no topical meaning, and it ranks third. The word from ranks fifth. The word with ranks sixth. A tool that claims to measure keyword density will always surface these words unless it filters them, and this tool's stop list contains only nine entries.

The stop list is i, he, she, it, and, me, my, you, and the. That's the entire list. Words like that, from, with, this, and which sail straight through. The length filter drops anything of three characters or fewer, which removes seo, the, and, and you before the stop list even gets a chance to act. The two filters overlap, and the length filter does most of the work.

There is no textarea on this page. You cannot paste an article into the tool. You cannot upload a file. The only input is a URL, and the only output is the table described above. The tool does not accept a target keyword, does not compare your page to a competitor's page, does not detect keyword stuffing in any meaningful sense, and does not compute phrase density. It counts single words, and only single words.

How to Use This Tool

1. Open the tool page. Find the input box above this article and make sure you have the URL of the page you want to analyze ready in your clipboard or another tab.
2. Paste the full URL. You can include the scheme or leave it off. The tool strips whatever scheme you provide and prepends plain http://, so https://example.com and example.com both resolve to the same fetch.
3. Submit the form. Press the Submit button and wait. The server fetches the page with a thirty second timeout, so a slow site can make you wait, but a normal page returns in a few seconds.
4. Read the summary line. The results page shows the URL you analyzed and the total number of distinct keywords in the table. For example.com that number was eight. For a long Wikipedia article it was much larger.
5. Scan the keyword table. Each row shows a keyword, its raw count, and its percentage of all kept tokens. The table is sorted by count, highest first, and it is not truncated, so a long page produces a very long table.
6. Interpret the percentages with care. A percentage is the count divided by the total number of kept tokens, and that total excludes short words and the nine stop words. The percentage is not a share of every word on the page.

Correcting the Old Description of This Tool

The previous version of this page made claims that the tool's own code contradicts. The old copy included a section titled "Single Words vs. Phrases: Why Both Matter," which implied that the tool measures phrase density alongside single-word density. It does not. There is no phrase detection anywhere in the pipeline. The tool splits text on single spaces and counts individual tokens. A two-word phrase like keyword density never appears as a row in the table, and no code path builds one.

The old copy also answered a question about whether the tool checks density against competitor pages. It does not. There is no competitor input, no second URL field, and no comparison logic in the controller. The tool fetches exactly one page, the one you provide, and reports on that page alone. The old page's answer to that question appears to have been written for a tool that does not exist on this server.

The old copy included a question titled "Why does my target keyword show 0%," which presupposes that the tool accepts a target keyword. It does not. There is no field for a target keyword, no place to type one, and no code that would compare a target against the fetched page's tokens. The question was meaningless for this tool, and the answer that accompanied it described behaviour that the code cannot produce.

The old copy implied that the tool applies substantial stop-word filtering. The real stop list contains nine words, and the length filter drops tokens of three characters or fewer. Words like that, from, with, this, and which are not filtered, and they dominate the top of any real content page. The Wikipedia test showed that in third place and from in fifth. A reader who expected those words to be filtered would find the table confusing.

The old copy also implied that the tool performs on-page keyword analysis in the sense that SEO professionals use the term, with attention to title tags, meta descriptions, and headings. This tool separates nothing. The html2text converter strips all tags and flattens the entire document into one text stream. A keyword that appears only in the title is counted exactly the same as a keyword that appears only in a paragraph. There is no per-section analysis, no weighting, and no structural awareness.

The old copy was roughly 2,475 words long. This correction section exists because the claims in that copy did not survive contact with the source code. The tool is simpler than the old page suggested, and the difference between the description and the reality was large enough to mislead a careful reader.

How the Numbers Are Produced

The pipeline from URL to percentage involves six distinct stages, and each stage changes what the final table contains. The output of this tool is an artifact of its filters.

The first stage is input handling. The submitted URL is trimmed of whitespace and lowercased. The scheme, if present, is stripped. Then http:// is prepended, always plain HTTP, never HTTPS. The www prefix is kept if it was in the original input. The result is validated, and an invalid input produces the message "Input Site is not valid!" A URL that passes validation but points to a server that does not respond produces "Requested URL looks down!" after the fetch attempt fails.

The second stage is the fetch itself. The site's curlGET function performs the request with a Chrome 87 user agent string, follows redirects, and enforces a thirty second timeout. No JavaScript is executed. This means any content that your browser would load through scripts, such as lazy-loaded images with descriptive alt text or client-side rendered frameworks, is absent from the fetched HTML. The tool sees the server's raw response, nothing more.

The third stage is HTML to text conversion. The converter removes the head, script, and style blocks entirely. All remaining tags are stripped. Adjacent elements without whitespace between them get glued together. The live example.com test produced the token domainthis, which came from the HTML sequence Example Domain</h1><p>This domain. The closing </h1> tag and the opening <p> tag had no whitespace between them, so the converter joined Domain and This into a single token.

The fourth stage is tokenization and filtering. The text is lowercased and split on single spaces. Each token must be longer than three characters. Tokens of one, two, or three characters are dropped, which removes seo, the, and, you, and thousands of other short words from any real page. The token must not be in the nine-word stop list, which is i, he, she, it, and, me, my, you, and the. The token must not contain http or mailto:. Punctuation is not stripped at this stage, so read. and read are separate tokens with separate counts.

The fifth stage is counting and percentage calculation. Each distinct token gets a count. The percentage is the count divided by the total number of kept tokens, multiplied by one hundred, and rounded to two decimal places. The total number of kept tokens is the sum of all counts after the fourth stage's filters. The results are sorted by count in descending order.

The sixth stage is the display filter. The controller drops any token that contains a digit or any of the characters ~ = + ? : _ [ ] " . ! @ # $ % ^ & * ( ) < > { } | \ /. This means a token like read. with a period attached is removed from the table, even though its count was included in the denominator during the percentage calculation. The token crawler, with a comma attached is likewise removed. The displayed table therefore shows only tokens that survived both the length and stop-list filters and the punctuation filter.

The result of this pipeline is a table that can be thousands of rows long. The Wikipedia test produced thousands of rows, each representing a distinct token that survived all filters. The table is not paginated and not truncated. A very long page produces a very long table, and the browser has to render all of it.

The displayed rows are a filtered subset of the counted tokens, and the percentages are computed before that final display filter runs. A token that appears in the denominator but not in the table inflates every percentage you see.

Why That, From, and With Top the Table

The Wikipedia Web crawler article test produced a top six of crawler, search, that, pages, from, and with. Three of those six words are function words with no topical meaning. Any reader who has used a word frequency tool before will recognize the pattern.

Function words like that, from, with, this, and which are among the most common words in English. They appear in almost every sentence, regardless of the topic. A page about Web crawlers uses that as a relative pronoun, from as a preposition, and with as a conjunction or preposition. These words carry grammatical weight, not topical weight. A keyword density tool that does not filter them will always rank them near the top of any sufficiently long text.

The stop list on this tool contains nine words, and none of them are that, from, with, this, or which. The length filter drops words of three characters or fewer, which removes the, and, you, and seo, but that has four characters, from has four, with has four, this has four, and which has five. They all clear the length bar and sail past the stop list.

The result is that the top of the table is dominated by grammar, not content. The Wikipedia test showed that with a count in the fifties, from with a count in the forties, and with with a count in the thirties. The word crawler led the list, but the gap between the topical leader and the function words is narrow. On a page with less repetitive terminology, a function word would take the top spot.

This behaviour follows directly from the filtering rules in the source code. The tool counts what the rules let through, and the rules let function words through. If you want a table that excludes that, from, and with, you need a tool with a larger stop list or a part-of-speech filter. This tool has neither.

You should read the table as a raw frequency count with light filtering. The word that with a count in the fifties tells you nothing about the page's subject matter. The word crawler with a count in the sixties tells you a great deal. The table mixes both kinds of information, and separating them is your job.

Why Short Keywords Never Appear

The length filter drops every token of three characters or fewer. This single rule removes an enormous share of the words on any English page, and it explains why the table never shows seo, the, and, you, for, are, or not. The rule exists in the code as a simple comparison, and its effect on the output is dramatic.

Consider the word seo. It has three characters. It is dropped. A page about search engine optimization might use seo dozens of times, and the tool will never report it. The word the has three characters. It is dropped, even though it is the most common word in English. The word and has three characters. It is dropped, even though it appears in the stop list anyway. The length filter and the stop list overlap for and and the, but the length filter acts first and removes far more words.

The word you has three characters. It is dropped, even though it is in the stop list. The word for has three characters. It is dropped. The word are has three characters. It is dropped. The word not has three characters. It is dropped. A page written in the second person, addressing the reader as you, will show no trace of that word in the table.

Short keywords, which are often the most commercially valuable terms in SEO, never appear in this tool's output. A three-letter keyword like seo is invisible. A four-letter keyword like free survives the length filter, but only if it is not in the stop list and does not carry punctuation. The tool's design biases the table toward words of four characters or more.

This is not a configuration you can change from the web interface. There is no setting for minimum word length, no option to include short words, and no advanced mode. The length filter is hard-coded into the pipeline. If you need to count three-letter words, this tool cannot do it.

The old page's question about a target keyword showing zero percent was partly a symptom of this length filter. A target keyword like seo would show zero percent because the token is dropped before counting. A target keyword like free seo tools would show zero percent because the tool does not count phrases and because seo is dropped by length. The tool never had a target keyword input, so the question was doubly meaningless.

How to Interpret a Density Figure in 2026

The concept of keyword density has a long history in SEO, and the idea of a magic percentage has been dead for years. The old rule of thumb, repeated throughout the 2000s, was that a keyword should appear at a density of one to three percent of the words on a page. That rule was never grounded in any search engine's documented behaviour, and modern search engines have explicitly stated that they do not use keyword density as a ranking factor in the way the old rule assumed.

Google's public documentation on search quality has, for many years, emphasized relevance and user experience over mechanical ratios. The company's Search Central documentation discusses keywords in the context of creating useful content, not in the context of hitting a target percentage. John Mueller, a long-time Google Search Advocate, has answered questions about keyword density by saying that it is not something site owners need to worry about. The consensus among SEO practitioners in 2026 is that density is a diagnostic signal at best, and a distraction at worst.

You can use the percentage this tool reports as a rough measure of emphasis. If a page mentions crawler dozens of times out of a few thousand kept tokens, the author clearly wrote about crawlers. The percentage tells you the relative prominence of that word within the filtered token set. It does not tell you whether the page ranks well, whether Google considers the page relevant, or whether the page would benefit from more mentions.

The percentage is also distorted by the tool's own filters. The denominator excludes all tokens of three characters or fewer, which removes a large share of the page's actual words. The denominator also excludes the nine stop-list words, though most of those are already removed by the length filter. The denominator includes tokens that carry punctuation, like read. and crawler,, even though those tokens are removed from the displayed table. Every percentage you see is therefore higher than it would be if the denominator included every word on the page.

Compare counts within the table rather than percentages across different pages. The count for crawler tells you that the author used that word far more often than pages or search. The count is a direct measure of frequency within the filtered set. The percentage adds a normalization that makes comparison possible across pages of different lengths, but the normalization is based on a denominator that no reader can reconstruct from the displayed table.

This tool gives you a frequency table with a normalization column, and the normalization is internally consistent but externally misleading. Use the counts to see what a page emphasizes. Ignore the percentages unless you understand exactly what the denominator contains.

What the Tool Does Not Do

The list of features this tool lacks is longer than the list of features it has. That is not a criticism of the tool. It is a warning to anyone who arrives with expectations shaped by the old page's copy or by other keyword tools they have used.

The tool does not count phrases. There is no code path that builds two-word or three-word sequences. The text is split on single spaces, and each token is counted independently. The phrase keyword density never appears as a row. The phrase web crawler never appears as a row. If you need phrase frequency, you need a different tool.

The tool does not accept a target keyword. There is no input field for one, and no comparison logic that would tell you how often your target appears. The old page's question about a target keyword showing zero percent was based on a feature that does not exist.

The tool does not perform competitor analysis. It fetches one URL, the one you provide, and reports on that page alone. There is no second URL field, no side-by-side comparison, and no code that would compute relative density between two pages.

The tool does not apply a meaningful stop-word list. The list contains nine words, and the length filter removes most of them anyway. Function words like that, from, and with dominate the top of any real content page. The tool does not filter them, and it does not claim to.

The tool does not stem words. The Wikipedia test showed crawler, crawling, and crawlers as separate rows with separate counts. A stemming tool would group them under a single root. This tool treats each surface form as a distinct token.

The tool does not separate page sections. The html2text converter flattens the entire document into one text stream. Title tags, meta descriptions, headings, and body paragraphs are all mixed together. A keyword in the title counts the same as a keyword in a paragraph.

The tool does not execute JavaScript. The fetch uses a plain HTTP client with an older Chrome user agent, but no browser engine runs the page's scripts. Content that loads dynamically is invisible to the tool.

The tool does not handle pasted text. There is no textarea on the page. The only input is a URL field, and the tool fetches whatever that URL points to.

The tool does not truncate its output. The Wikipedia test produced a table with thousands of rows, and the tool rendered all of them. A page with tens of thousands of distinct tokens would produce a table of tens of thousands of rows.

The tool does not detect keyword stuffing in any meaningful sense. It reports raw counts, and an unusually high count for a single word might indicate stuffing, but the tool has no threshold, no alert, and no judgement about what count is too high.

The Glued Token Artifact

The live example.com test produced a token that deserves special attention. The token was domainthis, and it appeared in the table with a count of one and a percentage of ten. No human writer ever typed domainthis. The token is an artifact of the HTML to text conversion.

The source HTML of example.com contains a structure like Example Domain</h1><p>This domain. The closing </h1> tag and the opening <p> tag sit next to each other with no whitespace between them. The html2text converter strips the tags but does not insert whitespace where the tags were. The text Domain and the text This therefore run together into a single token, which becomes domainthis after lowercasing.

This artifact is not unique to example.com. Any page with adjacent HTML elements that lack whitespace between them will produce glued tokens. A list item that ends with </li> immediately followed by <li> with no whitespace will glue the last word of one item to the first word of the next. A heading followed immediately by a paragraph will glue the heading's last word to the paragraph's first word.

The glued token domainthis survived the length filter because it has ten characters. It survived the stop list because it is not one of the nine listed words. It survived the punctuation filter because it contains no punctuation. It therefore appears in the table as a legitimate keyword with a count of one.

The percentage of ten for domainthis is a consequence of the tiny denominator. The example.com page is short, and after filtering, only eight tokens remained. Eight tokens appeared in the table, each with a count of one and ten percent, which shows the denominator was ten; two punctuation-glued tokens were dropped from the display while their counts stayed in the denominator. The math is internally consistent, but the result looks odd because the page is so short.

You should always read the table with an eye for artifacts. A token that looks like two words glued together is not a keyword. It is a conversion error. A token that carries punctuation is a different token from the same word without punctuation. The tool's output is a faithful record of its pipeline's behaviour.

Limitations and Honest Boundaries

Every tool has limits, and this one has limits that are visible in its source code. The most important limit is that the tool fetches only the raw HTML that a server delivers to a plain HTTP client. It does not render the page, execute JavaScript, or wait for dynamic content. A modern single-page application that builds its content in the browser will appear nearly empty to this tool.

The fetch uses plain HTTP. The tool strips whatever scheme you provide and prepends http://. A site that redirects from HTTP to HTTPS will be followed, because the fetch follows redirects, but a site that refuses plain HTTP connections will fail. The thirty second timeout means that a slow server can produce the "Requested URL looks down!" error even if the site is alive.

The tokenization is naive. Text is split on single spaces, so any punctuation that touches a word becomes part of the token. The word read. with a period is a different token from read without one. The word crawler, with a comma is different from crawler. The display filter removes tokens that contain punctuation, but their counts still affect the percentages. The result is that the displayed table's percentages do not sum to one hundred, and the displayed counts do not sum to the denominator.

The stop list is nine words long. It does not include that, from, with, this, or which, so those words appear in the table and often rank near the top. The length filter removes words of three characters or fewer, which is a blunt instrument that removes seo and the alike. There is no part-of-speech tagging, no named entity recognition, and no semantic understanding.

The tool does not stem. The Wikipedia test showed crawler, crawling, and crawlers as separate rows. A page that uses many inflected forms of the same root will spread its counts across multiple rows, making each individual form look less prominent than the root would if grouped.

The tool does not analyze page structure. Title tags, meta descriptions, and headings are not separated from body text. The html2text converter flattens everything into one stream. If you want to know whether a keyword appears in the title tag, this tool cannot tell you.

The output table can be enormous. The Wikipedia test produced thousands of rows, and the tool rendered all of them. A page with a large vocabulary will produce a table that is difficult to scan. There is no pagination, no search within results, and no way to filter the table to a subset of words.

The rate limit is worth understanding. This tool has no CAPTCHA and no tool-specific request cap. The site as a whole applies a shared throttle to every page. If one visitor address makes more than roughly fifteen requests within a single second, that address receives a 503 error for the rest of the day. For a normal user running a few analyses, this limit is irrelevant. For someone scripting hundreds of requests, it will bite.

This tool is a straightforward word frequency counter with light filtering, and its output reflects its simple pipeline. Use it for what it does well, which is showing the raw frequency of single words in a fetched page's text. Do not use it for phrase analysis, competitor comparison, or any interpretation that requires a richer model of language.

The Wikipedia Test in Detail

The live test that produced the large table is worth examining closely because it reveals the tool's behaviour on a realistic, content-rich page. The Wikipedia article on Web crawlers spans several sections. It is exactly the kind of page that a keyword analysis tool should handle gracefully.

The top six rows were crawler, search, that, pages, from, and with, in descending order of count. The topical words crawler, search, and pages lead the list, which makes sense for an article about Web crawlers. The function words that, from, and with follow closely behind.

The presence of that, from, and with in the top six is the clearest demonstration of the tool's minimal stop list. A tool with a proper stop list of several hundred words would remove all three. This tool removes nine words, and none of those nine are that, from, or with. The length filter removes the and and, but that has four characters and survives.

The Wikipedia test also demonstrated the absence of stemming. The table contained crawler, crawling, and crawlers as separate rows. If the tool stemmed words, these three forms would be grouped under a single root, and the combined count would be higher than any individual form. The tool does not stem, so each surface form stands alone.

The table's length is itself a finding. A page with a rich vocabulary produces a table with thousands of rows. The tool does not paginate or truncate, so the browser must render all of them. On a slower device, this can take a moment. The tool's output is complete, but completeness comes at the cost of scanability.

The percentages in the Wikipedia test are worth checking. The word crawler with a count in the sixties and a percentage near one and a half implies a denominator of roughly four thousand kept tokens. The word search with a count in the fifties implies a similar denominator. The percentages are consistent with the code's formula, which divides each count by the total number of kept tokens.

The denominator of roughly four thousand is far smaller than the total word count of the Wikipedia article. The length filter removes every word of three characters or fewer, which eliminates a huge share of English prose. The stop list removes nine more words, though most are already gone. The denominator is therefore a filtered subset, and every percentage is inflated relative to a denominator that included all words.

Related Tools

If you need to discover new keyword ideas rather than analyze an existing page, the Keywords Suggestion Tool on this site can generate related terms from a seed keyword.

When you want to understand the balance between the HTML code and the visible text on a page, the Code to Text Ratio Checker measures that proportion directly.

For a structural look at a page's title, description, and heading tags, the Meta Tags Analyzer reports on the metadata that this keyword tool ignores.

Frequently Asked Questions

Why does the table show words like that, from, and with?

The tool's stop list contains only nine words, and none of them are that, from, or with. The length filter removes words of three characters or fewer, but these function words all have four or more characters, so they survive. On any real content page, they will appear near the top of the table.

Why does my three-letter keyword never show up?

The length filter drops every token of three characters or fewer before counting. A keyword like seo has three characters and is removed. There is no setting to change this behaviour, and no way to include short words in the output.

Does this tool check keyword density against competitor pages?

No. The tool fetches exactly one URL, the one you provide, and reports on that page alone. There is no competitor input field and no comparison logic. The old version of this page claimed otherwise, but the source code contains no such feature.

What does the percentage column actually mean?

The percentage is the token's count divided by the total number of kept tokens, multiplied by one hundred, and rounded to two decimal places. The denominator excludes all words of three characters or fewer and the nine stop-list words. It also includes tokens with punctuation attached, even though those tokens are removed from the displayed table.

Why did the example.com test produce a token called domainthis?

The HTML on example.com has a heading followed immediately by a paragraph with no whitespace between the tags. The html2text converter strips the tags but does not insert whitespace, so Domain and This run together into one token. This is a conversion artifact, not a real word.

Is there a limit on how many times I can use this tool?

There is no CAPTCHA and no tool-specific request cap. The site applies a shared throttle to every page, and more than roughly fifteen requests from one address within a single second will block that address for the rest of the day. Normal use, a few analyses per hour, will never approach this limit.