Make the comparison explicit.

One comparison of counted items

List A is the chosen baseline and List B is the chosen comparison. Each retained line contributes one occurrence. If the same key appears three times, it counts three times. The calculator compares quantities of text keys; it does not establish that an object or person exists, or that a physical inventory changed.

For a particular key, let a be its occurrence count in A and b its count in B. Shared occurrences are min(a,b). Removed occurrences are max(a−b,0). Added occurrences are max(b−a,0). Those last two are directional: swapping the lists swaps added and removed while leaving shared counts unchanged.

The totals satisfy two useful checks: A occurrences = shared + removed and B occurrences = shared + added. These identities hold after the selected normalization and blank-line rules, not necessarily for every physical line in the pasted text.

A distinct key is a different normalized string. The union counts keys found in either list; shared distinct keys appear in both. A repeated occurrence after the first contributes to the occurrence total but not another distinct key. That is why a list with four lines can have only three distinct items.

Four lines are not four different keys

For bolts the counts are a=1 and b=0, so one bolt occurrence is removed. For washers the counts are a=2 and b=1: one is shared and one removed. Nuts have a=1 and b=2: one is shared and one added. Pins have a=0 and b=1: one is added.

Adding those rows gives two shared occurrences, two removed and two added. Both lists total four occurrences. Their distinct union has four keys, with two shared distinct keys, one only-A key and one only-B key. Each list has one repeated occurrence after its first instance.

A comparison based only on unique set membership would report bolts only in A and pins only in B. It would miss the washer and nut quantity changes. Listdelta shows both distinct-key counts and duplicate-preserving occurrence counts so those two questions stay clear.

Define sameness before counting

Outer whitespace

Trimming is on in the example. It applies JavaScript’s trim() to the start and end of each physical line. Leading and trailing whitespace is removed; spaces or tabs inside an item remain significant. With trimming off, a line consisting of spaces is a nonempty item. A truly empty string is always ignored.

ASCII letter case

Case is preserved by default. The optional ASCII mode changes only letters A through Z to a through z. “PART-A” and “part-a” then share a key. Non-ASCII uppercase and lowercase letters remain separate. This is intentionally not advertised as full Unicode case folding or locale-aware name comparison.

Canonical Unicode composition

With normalization set to None, strings compare by their exact code points. The visually similar texts composed from U+00E9 and from U+0065 U+0301 remain different. The optional NFC setting canonically composes equivalent Unicode sequences so this pair shares a key.

NFC is not compatibility normalization. It does not generally merge typographic alternatives such as a full-width A and an ordinary A. The tool does not infer accents, transliterations, spelling corrections or the identity of names. Processing order is outer trim, optional NFC, then optional ASCII case conversion.

Keys appear as JSON-quoted strings. Expand a row’s Code points disclosure when invisible characters or visually similar letters matter. Different strings can look alike even when neither whitespace nor NFC explains their difference.

Exactly what becomes an item

The input accepts plain text. CRLF, LF and CR terminate records. One final line terminator does not create another record: apple\n contains one physical line. apple\n\n contains the apple line and one blank line. Empty input has zero physical lines. Blank keys after the chosen options are ignored and their count is reported separately.

One empty list is valid and shows the other list’s unmatched occurrences. Both empty lists are also a valid empty comparison with zero items. Neither case is an input failure. Unsupported control characters or unpaired Unicode surrogates are rejected so exports do not silently replace entered text.

The software accepts at most 2,000 physical lines and 250,000 UTF-16 code units in each list, with no more than 500 Unicode code points on an individual physical line. Blank lines count toward the line limit. These bounds describe software capacity, not an accuracy threshold.

Commas, semicolons and quoted phrases remain part of one line. The tool does not parse CSV columns or detect headers. A header pasted as its own line is counted as an item. Reordering the lines does not change the mathematical comparison; rows are displayed in first-appearance order from A, followed by B-only keys in B order.

A report of your chosen comparison

Text and CSV reports are generated locally after a valid comparison. The table shows 50 keys per page, but every export includes all keys, regardless of the current page. Changing an input or option calculates a fresh result and clears old manual-copy text; invalid input disables reports until corrected.

JSON quoting makes keys explicit in reports. For example, a preserved tab becomes \t, and selected invisible or directional code points are written as Unicode escapes. Decode the JSON string if you need its exact underlying key. CSV also retains the first original A and B line associated with a key, not every original occurrence.

CSV values are quoted and keys are stored as JSON strings, rather than raw spreadsheet formula-looking text. Import columns as text when a spreadsheet’s automatic formatting matters. The report is not a guarantee about another application’s import behavior or a substitute for keeping your original lists.

There is no upload, download-from-URL, shared workspace or saved comparison account. Refreshing or leaving the page may lose the pasted lists. Avoid pasting sensitive material into a device or browser you do not trust.

Definitions and implementation sources

The official Python Counter documentation describes counted bags or multisets, including shared minimum counts and positive count differences. Listdelta independently implements finite line counts in JavaScript; it does not run Python or copy that documentation’s examples.

The MDN explanation of String.normalize() supports the stated NFC behavior, and MDN’s trim() reference describes the optional outer-whitespace operation. These sources were read during preparation on 19 October 2026. Our original washer/nut example and matching rules are stated in full so you can check them without an external service.