About FilterBlade

FilterBlade at this site is an independent, unofficial fan-made toolkit and guide resource for Path of Exile players. It is not affiliated with, endorsed by, or operated by Grinding Gear Games, NeverSink, or filterblade.xyz. The similar subject matter should not be mistaken for a shared service or official connection. Our purpose is narrower: provide original browser tools and practical explanations that help you understand what your own filter is doing before you rely on it during play.

A toolkit built around understandable decisions

Loot filters determine which drops deserve attention and how that attention is requested. A clear label can help you identify an upgrade; an overly broad hiding rule can remove information you still need. These decisions depend on your character, goals, and willingness to inspect optional items. This site treats filtering as a set of choices that should be explainable, not as a contest to use the most aggressive preset available.

The Loot Filter Builder starts with original starter data. It does not fetch live economy prices, copy NeverSink’s tiers, connect to your game account, or synchronize filters through OAuth. You generate and review a local file, then activate it using a supported workflow in your own client. Starter data is intentionally described as a starting point rather than a complete market-aware recommendation.

Who is behind the material

The content and code are supplied as an original site package. No verified personal biography, professional gaming credential, or named legal operator has been supplied with that package. We do not fill that gap with an invented expert profile, a fictional team, or claims about years of experience. A WordPress publishing account identifies the account used to publish an article; it should not be interpreted as an independently verified qualification.

Questions about site operation, authorship, and corrections can be directed through Contact once the site’s owner has configured a working recipient. Operator identity and applicable legal details require owner review before public launch. This transparency matters because a useful article should stand on its explanation and evidence, not on credentials that the reader cannot verify.

How the tools and guides are developed

Language explanations are grounded in the official item-filter documentation where available. The toolkit separates syntax checks, item evaluation, contrast calculations, and text comparison because each answers a different question. A file can be syntactically valid yet unsuitable for your character. A readable browser label may still need testing against the game’s effects and terrain. A comparison can reveal a changed block without knowing whether that change was wise.

Where a tool implements only part of the language, it should report the unsupported condition or missing information. An unresolved import is not a successful evaluation. A sound file that has not been supplied is unverified, not necessarily missing. A documentation review date is not proof of a client patch test. These distinctions are central to the site’s methodology and are explained further in the Editorial Policy.

What stays local, and what does not

The browser tools are designed to process pasted filter and item text locally rather than uploading it for analysis. Optional local saving depends on the tool and browser settings. Clearing site data may remove saved preferences or checklist progress, so downloaded backups remain important. The website still needs ordinary network requests to deliver pages and assets; local tool processing does not mean browsing the site is anonymous or offline.

A contact submission is different from a tool input. Sending a message transmits the information in that form so a recipient can handle it. Do not include passwords, account recovery codes, payment information, or private filter comments that are irrelevant to the question. The site’s final privacy notice must reflect the host, mail service, optional analytics, and other features actually enabled by its operator.

Corrections are part of the process

If you find a factual error or a tool result that contradicts a supported case, include the page address, selected game, minimal input, expected result, and actual result in your report. Remove unnecessary personal information. A small reproducible example is more useful than an entire unexplained file. Reports are reviewed according to their impact and available evidence; no fixed response or repair time is guaranteed.

Significant corrections should explain what changed and whether earlier advice could have affected a user’s filter. Cosmetic edits need not imply that a new client test occurred. The blog, guides, and FAQ aim to help you ask better questions of your configuration. Keep a known-good backup, test important exceptions, and treat the actual game client as the final authority on whether your chosen file loads and behaves as intended.