Lucene/Solr Formatter
Format and validate Lucene/Solr queries with syntax highlighting
Query Input
Enter your Lucene/Solr query here
Formatted Query
javascript angular
Lucene/Solr Formatter
Format and validate Lucene/Solr queries with syntax highlighting
Features
- 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)
How to use
- 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).
Tips & Best Practices
- 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.
FAQ
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.