Lucene/Solr Formatter
Формат и validate Lucene/Solr queries с синтаксис highlighting
Query Ввод
Введите ваш Lucene/Solr query here
Formatted Query
javascript angular
Lucene/Solr Formatter
Формат и validate Lucene/Solr queries с синтаксис highlighting
Возможности
- Format Lucene and Solr query strings with proper syntax: field:value pairs, boolean operators (AND/OR/NOT), parentheses for grouping, range queries with [from TO to] / {from TO to}, fuzzy ~, boost ^
- Multi-dialect support: pure Lucene (Elasticsearch-compatible), Apache Solr (with function queries, local params, joins), and Elasticsearch Query String DSL
- Visual breakdown of the parsed query tree: shows fields, operators, and groupings as a hierarchical view alongside the formatted string — useful for reviewing complex queries before running them
- Validation pass: unmatched parentheses, missing field qualifiers, invalid range syntax, unsupported wildcards (leading * disallowed by Lucene default) — explains each issue with the spec reference
- Examples for common patterns: basic text search, fielded search, boolean compositions, ranges for numbers/dates, wildcard / regex, Solr function queries, nested groupings — copy-paste and tweak
- Optimization suggestions: replace `field:*` with `_exists_:field`, replace deeply-nested ORs with terms queries, hint at Constant Score wrappers for performance — actionable improvements
- Copy formatted query to clipboard ready for paste into Elasticsearch, Solr, OpenSearch consoles, or embed in code via QueryStringQueryBuilder
- Pure client-side: parsing and formatting run in your browser, no upload. Safe for queries against confidential indexes (PII, business data)
Как использовать
- Paste your query string into the input pane.
- Pick the dialect: Lucene (Elasticsearch-style), Solr, or Elasticsearch Query String DSL.
- Click Format. The output shows the formatted query plus a visual breakdown of fields and operators.
- Read the validation panel for any syntax errors or suspicious patterns flagged with line/column references.
- Browse the Examples panel for common patterns you can copy and modify.
- Copy the formatted query and paste into your search backend (Elasticsearch, Solr, OpenSearch).
Советы и лучшие практики
- Use parentheses generously for queries with mixed AND/OR operators; the formatter visualises the precedence but explicit parens make code reviewers' lives easier.
- For wildcard queries, prefer trailing wildcards (`field:term*`) over leading (`*term`). Reverse-engineer the index if you need leading-pattern matches.
- Wrap multi-word phrases in quotes (`"machine learning"`) to match the phrase; without quotes, ML returns docs with both words anywhere.
- For range queries, prefer `field:[start TO end}` (exclusive end) when working with date ranges aligned to day boundaries.
- Test queries first against a small sample index; complex compositions can match unexpectedly if precedence isn't what you assumed.
Вопросы и ответы
What's the difference between Lucene and Solr query syntax?
Lucene is the underlying query parser used by both Elasticsearch and Solr. Solr extends it with local params ({!type=edismax}), function queries (_val_:"recip(rord(date),1,1000,1000)"), join queries ({!join from=fk to=pk}), and qf/pf in eDisMax. If you're writing pure Lucene that Elasticsearch accepts, pick Lucene; if you use Solr-specific features, pick Solr.
Why does the validator flag `field:*` as a problem?
It does what you probably don't want: matches every document where the field exists. Most engines treat this as a wildcard query, which is slow and matches all values. Replace with `_exists_:field` (Elasticsearch) or `field:[* TO *]` (Lucene) for the "field-has-any-value" semantics, which is much faster.
How are leading wildcards (*foo) handled?
Lucene by default disallows leading wildcards because they require scanning the entire term index (no prefix to seek to). Set allow_leading_wildcard=true in your index settings if you really need them, but they're an order of magnitude slower than trailing wildcards (foo*).
What's a fuzzy query and when should I use one?
fuzzyQuery `quick~` matches terms within edit distance 2 (default). Useful for typo tolerance but slow on large indices. For better performance use `quick~1` (edit distance 1) or `quick~0.8` (similarity threshold). Avoid on free-text fields with millions of terms.
How does the boost (^N) modifier work?
`field:term^2.0` multiplies the relevance score for that match by 2.0. Combined with disMax or function_score queries, boosts let you tune ranking. Boost only affects scoring, not which documents match.
Why does the formatted output reorder my query?
Standard precedence: AND > OR; explicit parens > implicit; ranges and quoted phrases are atomic. The formatter inserts the implicit precedence as visible parens, which makes the query unambiguous to read. Logically equivalent to your input.
Can I format Elasticsearch DSL JSON queries here?
No — that's a different format (JSON-based). This tool handles the query string syntax used in the q parameter of /_search, the QueryStringQueryBuilder, or Kibana's search bar. For DSL JSON, use a JSON formatter and the Elasticsearch docs.
Is my query sent anywhere?
No. Parsing and formatting run in your browser. Safe for queries against internal/proprietary indexes; the query never leaves your tab.