Filter Formatter

Make a filter easier to inspect without rewriting its rules

A loot filter is easier to review when block headers stand out and instructions line up. Filter Formatter is a deliberately narrow text editor: it normalizes leading indentation and blank-line separation, not the intended meaning of a rule. It does not sort blocks, rename actions, update keywords, change quoted strings, remove comments, resolve imports, or optimize a filter. That narrow scope matters because rule order and exact arguments can affect which drops you see. Use the formatter to make a revision legible, then review the resulting text as a revision rather than treating tidiness as a correctness certificate.

Start with a source you can recover

Save your current .filter file somewhere outside the file you intend to edit. If working from an exported builder file, retain that export unchanged as a baseline. Paste your filter into the input field, load a local .filter or .txt file, or use Sample to inspect the layout before using your own data. A selected file is read in your browser; loading it is not uploading it to a game account. Check that the full input arrived, especially the last block, before formatting. Do not paste secrets into comments simply because an editor runs locally: a future copy or screenshot could expose them.

Choose indentation of two or four spaces. This sets leading spaces used for instructions under block headers; it does not change numeric arguments, trailing spaces, or spaces inside quotation marks. Toggle blank-line separation. When on, the formatter places a blank line before a top-level header or wherever there was already blank separation, collapsing runs of blank lines to one. When off, it removes blank lines rather than preserving old spacing. Press Format, inspect the result, and compare with the input before copying or downloading. Keep both versions so that you can identify a formatting-only edit later.

A worked layout example

Suppose this small constructed PoE 1 Normal example was pasted with inconsistent leading spaces. It demonstrates text layout, not an item-value recommendation:

# Keep this note
Show
 Rarity Rare
    SetTextColor 255 220 180


Hide
  Rarity Normal
  # Review this hide decision

With two-space indentation and blank-line separation enabled, the formatted output is:

# Keep this note

Show
  Rarity Rare
  SetTextColor 255 220 180

Hide
  Rarity Normal
  # Review this hide decision

The blank line before Show is intentional: Show begins a top-level block following a comment. The headers remain Show then Hide; arguments still say Rare, Normal, and the same color channels. The comment stays a comment. A final LF newline is added even when the input did not end with one. The formatter does not tell you whether hiding Normal items is appropriate, whether an earlier rule shadows the Hide, or whether the client accepts every line.

What stays intact, and what changes at the byte level

Quoted item names and class strings can include spaces that are part of the intended argument. For example, BaseType "Broad Sword" is not an invitation to collapse the space within quotes. Comments may explain why exceptions exist; deleting them for a shorter file would erase context. Import lines indicate dependencies and their placement matters. This formatter retains their text and position rather than moving them next to a similar-looking block. It does not read the referenced files.

Whitespace transformation is still a real textual change. Initial ASCII spaces and tabs are replaced with the chosen leading layout; blank lines are removed or separated according to the toggle. Output uses LF line endings and ends in a newline. A leading byte-order mark, if present, is retained. Characters after the leading indentation on nonblank lines, including trailing spaces, quoted strings, comment text, and internal spacing, remain intact. If an exact byte-for-byte format, line-ending style, or a no-final-newline convention is part of your workflow, keep and inspect the source rather than assuming the download reproduces it.

The formatter tokenizes lines to recognize headers. A malformed quoted line may stop formatting with an explicit error instead of producing output; this is not a general syntax validator. It does not fix a malformed quote, a typo in a keyword, an unsupported instruction, or an invalid game mode. If a condition, action, quoted value, comment, or block order appears to change, treat that as a substantive unexpected edit and return to the backup instead of calling it harmless formatting.

Use editing controls deliberately

Sample fills an illustrative file so you can learn the controls without risking a working filter. File loading reads your selected file into the input; check displayed contents before proceeding. Copy and Download export the formatted output, not the original input or a validation report. A downloaded file is a candidate revision, not a live filter selected by the client. Reset restores default inputs; Undo attempts to restore a recent input state in this session. Neither control is a durable revision history after reload or an overwrite. For real rollback, keep an original file in a separate location.

After copying output to an editor, inspect its saved extension. A .filter.txt file can masquerade as .filter when extensions are hidden. Give downloaded output a distinct revision name; the browser’s default download is text and may need to be saved as a proper .filter file for your local client workflow. Avoid overwriting a known-good file until after comparison, validation, and a client check. No browser button here can confirm which file your client has loaded.

Use formatting to make a review easier

Consider a long file where a specific rare-item Show precedes a broader fallback Hide. Inserting a pleasant blank line does not change the evaluation sequence. A broad early Show without Continue can prevent later exceptions from being reached; a later Hide can have a different effect when order changes. Read headers from top to bottom after formatting. Search for each Hide and Minimal and inspect its conditions and earlier relevant blocks. Check Continue usage against official language documentation instead of treating it as a generic ‘continue editing’ marker.

Run Filter Compare with the untouched original on the left and formatted output on the right. Expect leading whitespace and line-ending or blank-line differences, but inspect the exact result rather than trusting a summary count. The comparator’s block grouping is a navigation aid, not a proof of equivalence. Next use Filter Validator to check its supported syntax subset on the saved output. Finally load the intended revision in the client and test important drops. This sequence keeps presentation, syntax, and actual behavior separate.

Limits and failure cases

A formatter cannot infer whether a line that looks like a comment was meant to be a rule. It cannot decide whether a custom sound exists. An imported file may have its own indentation and errors; formatting the parent does not touch or validate that dependency. Text copied from a rich-text editor can contain curly quotation marks or hidden characters; making the left edge tidy does not make those valid filter syntax. Check original characters before repeatedly changing spacing in response to an error.

Input is capped at 5 MiB of UTF-8 text. If a file is too large or malformed for the supported operation, preserve the explicit error rather than assuming a partial output was exported. A short section can help clarify a layout pattern, but dependencies and earlier blocks change how the section behaves. If Copy fails due to clipboard permissions, use Download or manually select available output. Verify its destination rather than assuming your clipboard contains the latest result.

Questions before installation

Does tidier text run faster? This tool makes no performance claim. Its goal is readability. Will it fix a rejected file? No syntax repair is promised; read the client’s error and validate the saved source. Will it remove duplicate rules? No. Deleting a repeated block requires understanding why it exists. Does Undo replace a backup? No. Save a known-good original independently. What about an Import? Keep its path and inspect the referenced file separately.

Next step

For a rule-by-rule reading pass, use Filter Rule Explorer and the rule-reading guide. For a deliberate revision and rollback procedure, follow the safe editing guide. The authoritative language reference is GGG’s item-filter documentation; this page describes text transformation, not a test of a current patch.

Back to the tool ↑