Filter Compare

Review an update instead of trusting its filename

Filter Compare checks two supplied filter texts side by side. It reports a line diff and a structural diff of recognizable blocks, helping you focus on what changed before replacing a working revision. It does not parse the economic meaning of an item, prove semantic equivalence, or judge which revision is better. A single threshold operator can be more consequential than fifty altered colors.

Load the original and updated filter

Paste the baseline into Original filter on the left and the proposed revision into Updated filter on the right, or load a .filter or .txt file into each respective field. You can also drop a file onto a textarea. Press Compare filters after both texts are in place. The result is a JSON object with a summary of added, removed, and changed blocks, a block diff, a line diff, and a note explaining how changed blocks are paired. Copy result or Download result saves that report as plain text. Keep copies of both source files too: the report does not embed filenames, and it cannot reconstruct either full filter on its own.

Direction matters. Swapping inputs swaps what counts as added and removed. Before investigating a regression, check that the left really is your last known working revision. Note the two filenames and games in your own review notes; the tool does not infer game identity, select a game, or attach file metadata to the diff. Comparing a progression filter with a specialized farming filter is possible, but the report will not tell you whether the design differences are appropriate.

Read exact lines before summary counts

Start with the summary to gauge scope, then inspect the lines for exact changed operators, strings, and Import paths. In the JSON result, line entries have types such as same, added, or removed. The blocks view compares block headers and rule keys with their arguments; comments and Import statements appear in the line diff, not as compared blocks. A comment-only update therefore can change the line diff without increasing the block summary.

The comparison uses an alignment algorithm, not knowledge of an editor’s actions. Adjacent removed and added block runs are counted as changed where possible. A moved block can appear as removal and addition even if its contents are identical; a reshaped block can be paired with something you did not intend. Count labels are navigation aids rather than a historical record of edits. Check source order manually when a block seems to move.

Worked example: a boundary changes

Put this supported text in Original filter:

Show
    Rarity Rare
    ItemLevel >= 75
    SetFontSize 36

Put this text in Updated filter:

Show
    Rarity Rare
    ItemLevel > 75
    SetFontSize 36

After Compare filters, expect the summary to count one changed block, not a new category of items; the lines mark the former ItemLevel condition removed and the new one added. At item level 75 the old comparison matched and the new one does not. At 76 both conditions can match. This does not by itself establish a final Show or Hide verdict in a larger file: earlier terminating rules, later matches with Continue, imports, and the game’s default behavior can matter. Use the Item Tester with representative complete copied items and check the installed file in the client.

For a second comparison, keep rule arguments identical but move a broad Show block above a specific Hide exception. The summary may display removed and added blocks due to reordering. Even though each block’s contents remain familiar, order can change what gets reached. Review final order rather than assuming unchanged argument text implies unchanged behavior. The Filter Rule Explorer can help find both blocks by header or instruction keyword and inspect source line numbers; it does not itself evaluate item matches.

Prioritize risky differences

Inspect Show, Hide, Minimal, and Continue first. Then inspect condition operators, numerical boundaries, quoted class or base strings, and Import filenames. Confirm whether a newly removed fallback or manual category Hide accidentally expands exclusions. Next inspect styles: an altered alert sound or font size can be noticeable, but it should not distract you from a visibility change buried in the same diff. Cosmetic reformatting can create line noise; keeping functional and palette edits in separate revisions makes review easier.

If either source imports another file, compare that dependency separately. The parent text cannot reveal whether the referenced file changed since the last installation. Likewise, this tool cannot check custom sound availability or whether the game selected the intended filter. An empty diff establishes no detected textual difference between the supplied inputs; it does not establish identical installed behavior across different dependencies or clients.

Handle limits honestly

Each input is limited to 5 MiB of UTF-8 text. An oversized file is rejected instead of partially compared. Large or highly repetitive differences can also exceed the worker’s computation budget; the explicit incomplete-work error means no complete comparison report was produced. Do not call that an empty diff. Keep source revisions intact, compare smaller clearly labelled diagnostic sections, and review the whole file by another method before deployment. Re-running the comparison cancels the previous worker rather than silently mixing reports.

If nearly every line differs, first verify you did not reverse or misload inputs. Generator changes, broad reformatting, or entire block reorderings can create considerable noise. Identify a few high-risk sections and compare those deliberately, while marking a section-only diagnosis as such. A short isolated test can explain one condition; it is not a complete-file update review.

Interpret a report with no changed blocks

Imagine you changed only a comment from # league plan A to # league plan B. The line diff should mark a removal and addition, while the block summary remains at zero changes because comments are not part of block signatures. That is a useful distinction, not a bug: the line view preserves editing context and the block view groups executable rule text. Conversely, a single new condition can count as a changed block without proving that every item matched by that block now behaves differently. Counts tell you where to read, not how many drops change.

A report with no detected line differences is narrower still. It may mean you loaded the same file twice by mistake. Inspect the textarea contents and file revision names rather than concluding that an observed in-game change is imaginary. Imported dependencies, selected client filter, and a separate custom sound folder are outside these two text inputs.

Save a reproducible revision

Use Download result to keep the JSON report, then separately retain the old and new .filter files under distinct names. Record which filename was left and right, which game they belong to, and why significant Hide decisions changed. File comments and local paths can appear in exported line text, so inspect a report before sharing it publicly. A downloaded comparison is not a replacement filter and cannot be installed to change loot labels.

Run the new source through the Filter Validator after review. Resolve reported syntax errors before installing. If you changed only indentation or blank lines using Filter Formatter, expect a noisy line diff, but still inspect keywords, quoted text, and order rather than assuming formatting guarantees semantic equivalence. Then test wanted and unwanted examples and keep a rollback file until the client confirms the new revision. Comparison locates edits, validation checks supported syntax, testing traces supported rule paths, and client observation checks actual installation.

Questions people ask

Does no change mean no gameplay difference? Only supplied text was compared. Imports, sound assets, client selection, and game behavior are outside this output. Will it recommend the better filter? No. Your character’s needs and the merits of hidden items require judgment. Can I compare PoE 1 and PoE 2 files? Yes as text, but the result is not migration or compatibility checking. Why compare blocks and lines? Blocks give rule grouping while lines expose comments and exact value edits. Both perspectives help; neither proves equivalence.

Further reading

Follow the safe edit and test procedure, the strictness guide, and the installation guide before replacing a working file. For filter-language control flow consult GGG’s reference. This comparison runs locally on supplied text and does not use a live patch or economy feed.

Back to the tool ↑