You can count how many times a literal string appears in a block of text without building a pivot table at all by using a browser-based Count Occurrences tool that reads up to one million characters locally, returns the total number of matches, and lists the first 100 zero-based starting positions. Most searches for "how to use pivot table to count number of occurrences" come from people working in Excel, where the question usually means "tally every value in column B and show me how many rows each one owns." That pivot-table approach is genuinely useful inside a workbook, but the same counting question shows up constantly in plain text files, log lines, code snippets, CSV exports, and pasted prose, where a spreadsheet is either unavailable or simply too heavy. Count Occurrences handles that lighter case directly: paste the source, type the string to find, pick case sensitivity and overlap behavior, and the tool returns a numeric answer plus concrete positions. Every step runs inside your browser, no upload is performed, and the search is strictly literal, so punctuation such as dots, brackets, and asterisks does not need any escaping.
Why a Pivot Table Is Overkill for a Quick Text Count
A pivot table is the right answer when your data is already shaped like a spreadsheet, the column you want to tally is a real field, and a copy of Excel, LibreOffice Calc, or Google Sheets is open in front of you. None of those conditions are guaranteed for a chunk of text copied from a log file, a JSON dump, a chat transcript, or a long code sample. Spinning up a spreadsheet, importing the text, splitting it into rows, and configuring a pivot field just to learn whether the word "timeout" appears 14 or 17 times is a lot of friction for a single number.
Count Occurrences removes that friction. You paste the source text, enter the literal string you want to find, choose whether matching should care about case, decide whether matches may overlap, and read off the answer. The output is one count plus a short list of zero-based positions, and every byte of work happens on the local machine, so sensitive logs and unfinished drafts never leave the tab. For Excel users who would still rather stay in a workbook, the count text occurrences in Excel without formulas guide walks through the same tool applied to spreadsheet data.
Counting Text Occurrences Step by Step
The whole workflow lives on the Count Occurrences tool page and takes only a moment once your inputs are ready.
- Paste or type the source text you want to search. You can paste up to 1,000,000 characters. The tool does not trim, normalize line endings, collapse whitespace, or strip anything from this input; whatever you paste is what gets searched.
- Enter the literal text to find and choose case sensitivity and overlap behavior. The search string can be up to 1,000 characters and may include spaces, tabs, line breaks, emoji, or ordinary Unicode. Pick case-sensitive or case-insensitive matching, and pick overlap or non-overlap mode.
- Count matches and review the total plus the first 100 zero-based starting positions. The reported total is never truncated, but only the first 100 positions are listed so that a result with hundreds of thousands of matches stays readable. Editing any input or option clears the old count, so a stale number cannot be mistaken for the current settings.
If you want to repeat the count on a fresh body of text, just replace the source field. The output below the form resets the moment the source, search string, case option, or overlap option changes, which protects you from acting on a number that no longer reflects what is on screen.
Overlap vs. Non-Overlap Mode Explained
Overlap is the most surprising control on the form, because the same search can produce two different counts depending on which mode you pick. Non-overlapping mode, which is the default mental model most people carry over from spreadsheet COUNTIF behavior, advances the search pointer past the entire matched string after each hit. Overlapping mode instead advances just one JavaScript string unit, so the next match can begin inside the previous one. The two behaviors are documented in the JavaScript String indexOf reference, which is the underlying lookup that gets repeated until the end of the source.
The cleanest way to see the difference is to search for the two-character string aa inside the four-character source aaaa. The table below shows what each mode reports.
| Mode | Search string | Source | Starting positions found | Total count |
|---|---|---|---|---|
| Non-overlap | aa | aaaa | 0, 2 | 2 |
| Overlap | aa | aaaa | 0, 1, 2 | 3 |
The worked example walks through the math one step at a time. In non-overlap mode the search starts at offset 0, finds aa immediately, and jumps forward by the full search length of 2 to offset 2, where it finds a second aa and stops with a count of 2. In overlap mode the search starts at offset 0, finds aa, and jumps forward by just 1 to offset 1, where it finds a second aa beginning at the second character, then jumps to offset 2, finds a third match, and ends with a count of 3.
Use non-overlap mode when you want to know how many separate replacements a literal find-and-replace operation would make, and use overlap mode for sequence analysis where every adjacent occurrence matters, such as counting how many times a digram, bigram, or repeating token appears in a row.
Reading the Zero-Based Position Numbers
Every offset that the tool prints is a JavaScript UTF-16 string index, which means the very first character of your source sits at position 0, not 1. Most ordinary English letters, digits, spaces, tabs, and common punctuation each consume one offset, so positions line up cleanly with the visible characters you can count on your screen. Characters that are represented by surrogate pairs, which includes most emoji and some less common CJK glyphs, consume two UTF-16 code units instead of one, so an emoji sitting at the start of a line pushes every later position up by one extra unit.
Because of that, the tool is honest about what its positions mean: they are reproducible JavaScript string indexes, useful for browser console work and for matching the offsets you would see from a literal index lookup, not grapheme indexes that line up with what a human reader perceives as one character. If you paste the same source back in twice, you will get the same offsets, because the tool does not rewrite your input. It also does not perform any Unicode normalization, accent folding, or locale-specific case rules beyond a simple English-locale lowercase conversion when case-insensitive mode is on.
Practical Use Cases for Counting Text Occurrences
The tool is a practical text utility rather than a full linguistic engine, which is exactly the shape that most ad-hoc counting jobs need. Common uses include checking whether a repeated word like "the the" slipped into a draft, counting how many times a separator such as a tab, pipe, or semicolon appears in a CSV-like row, tallying log markers like ERROR or WARN across a pasted slice of an access log, and verifying how many times a specific code fragment, identifier, or punctuation string shows up in a snippet.
You can also use it to count exact phrases, including phrases that span a newline when the search field contains that newline, and to confirm how many times an ID, ticket number, or email-shaped string repeats inside a dump. For counts grouped by every distinct word in the source rather than by a single chosen string, switch to the Word Counter. For changing those matches instead of just counting them, the Find and Replace tool handles the same literal-match rules with a replacement field. For comparing two bodies of text side by side, the Text Diff Checker is the better fit.
Limits, Edge Cases, and What the Tool Does Not Do
A few practical limits keep the tool responsive and prevent an accidental huge result from freezing the tab. The source text is capped at 1,000,000 characters and the search string at 1,000 characters, both well past the size of most snippets a person would paste for a quick count. An empty search string is rejected, because it would otherwise match at every boundary between characters and produce an ambiguous answer. A search longer than the remaining source returns zero, which is the correct result rather than an error.
The tool intentionally does not compile a regular expression, so there is no concept of an "invalid pattern" that can break the search. A period matches a literal period, an asterisk matches a literal asterisk, and square brackets carry no special syntax. There is also no whole-word mode, no fuzzy matching, no stemming, no wildcard syntax, no Unicode normalization, no replacement action, and no file upload parser. The result you see is exactly the count and the first 100 positions, with no download produced, because the core output is just a small numeric answer.
Case-insensitive mode converts both the source and the search text with English-locale lowercase behavior before comparing, and the printed offsets are still measured against the original text. That makes the output predictable across browsers but means locale-specific equivalence, composed-versus-decomposed Unicode forms, accent folding, and script-specific case rules are not inferred; if you need any of those, treat the tool as a starting point and double-check the result manually.