Boolean Search for Legal Databases

Boolean Search Is Not Dead

Boolean search for legal databases means combining keywords with operators (AND, OR, NOT), exact phrases in quotes, proximity connectors like /s and /p, and the root expander ! to return every matching document with no summarization and no guessing. It is the precision tool of legal research: when you know the exact statute, term of art, or citation, Boolean legal research beats natural-language search on recall and repeatability.

Everyone wants to talk about AI search. The natural-language query feels like magic when you first use it: ask a question in plain English, get back cited law. That surface is real and useful.

But here's the thing: when a lawyer knows exactly what they're looking for, Boolean search for legal databases is faster and more precise than any AI model. A senior litigator hunting for the statute behind a qualified-immunity claim, 42 U.S.C. § 1983, or for Supreme Court opinions applying it, doesn't need an AI to "understand" their intent.

They need a search engine that returns every matching result, no hallucinations, no summarization, no guesswork.

Boolean search gives you that control. And if you're building a legal tech product, integrating it into your workflow through an API is one of the most practical things you can do.

TL;DR

• Boolean operators (AND, OR, NOT), phrase quoting, NEAR proximity, and trailing wildcards give you precise, repeatable legal search with zero hallucination risk.
• A hosted statutes API typically parses Boolean queries at POST /api/v1/statutes/search and returns structured JSON with citation, title, and snippet fields across the US Code, the CFR, federal rules, and all 50 state codes. Case-law search, citation lookups, and ask-a-question flows are in-product features at most vendors, not public API endpoints.
• Inside an in-product research surface, the same Boolean grammar usually applies to opinion search, scoped across the three federal court tiers: U.S. Supreme Court, the U.S. Courts of Appeals, and the U.S. District Courts.
• The seven mistakes that waste hours: unquoted phrases, wrong operator precedence, over-stacking AND, aggressive NOT, ambiguous section numbers (28 U.S.C. § 1331 vs a bare "Section 1331"), missed citation formats, and leading or mid-word wildcards.
• Best workflow: Boolean to find the right statutes via the API, then analyze them with your own LLM layer (or with an in-product surface that adds case-law grounding on top).

Part of our MCP and developer guide series.

For related MCP / API / developer coverage, see How to Pull US Code and Statutes Programmatically: A USC API Guide.

The Operators You Need to Know

If you've written SQL WHERE clauses or used regex, Boolean search will feel familiar. The syntax is simpler than either.

AND

Both terms must appear in the document.

"qualified immunity" AND "excessive force"

This returns cases that discuss both qualified immunity and excessive force, the core of most Section 1983 police-misconduct claims.

Without the AND, you'd get thousands of irrelevant results where only one term appears.

OR

Either term can appear. Use this when the same legal concept goes by multiple names.

"Section 1983" OR "42 U.S.C. 1983"

Briefs and opinions cite the civil-rights statute both ways. OR captures all of them in a single query.

NOT

Exclude results containing a specific term.

"fair use" NOT "parody"

A copyright lawyer researching transformative-use defenses under 17 U.S.C. § 107 often wants to set aside the parody line of cases. NOT strips those out.

Phrase Search

Wrap exact phrases in double quotes to match them as a unit.

"warrantless search"

Without quotes, a search for warrantless search would return every document containing either word. With quotes, you only get documents where the exact phrase appears together.

Proximity Search (/n, /s, /p)

This one is underrated. Proximity operators find terms that appear within a specified distance of each other. On the major legal platforms the grammar is /n (within n words), /s (same sentence), and /p (same paragraph).

"Fourth Amendment" /5 "cell-site"

This finds cases where "Fourth Amendment" and "cell-site" appear within 5 words of each other, the territory of Carpenter v. United States, 585 U.S. 296 (2018). It's more flexible than a phrase search (which requires exact adjacency) but more precise than AND (which just requires both terms somewhere in the document).

/s and /p are heavier hammers: "reasonable suspicion" /s Terry keeps both terms in the same sentence, which is usually where a court states the rule. On Lexis, /p is processed as /75 words and /s as /25 words (Stanford Law School, Terms and Connectors Searching, accessed June 2026).

Proximity search is especially useful for finding specific legal tests. US courts often formulate tests using particular language, but the exact phrasing varies slightly across opinions.

Wildcards and the Root Expander (!)

There are two different tools here, and people conflate them.

The root expander (!) matches a root plus any number of trailing characters. On Westlaw, Lexis, and Bloomberg Law it is the exclamation point.

neglig!

This single query matches negligence, negligent, negligently, and any other variation. Useful when you want every form of a legal concept without writing out each variant.

The wildcard (*) replaces a fixed number of characters inside or at the end of a word. On Westlaw and Bloomberg, * stands for one variable character (wom*n matches woman and women). On Lexis, * behaves like a root expander and the single-character wildcard is ? instead (Stanford Law School and Drake University Law Library guides, accessed June 2026).

Many free and hosted search APIs follow the simpler convention used in this guide's code samples: a trailing * acts as the root expander (neglig*). Always check your platform's docs before you assume a symbol carries over.

Operator Reference: Westlaw vs Lexis vs Bloomberg vs Free Tools

The grammar is the same idea everywhere, but the exact symbols drift between platforms. This table is sourced from the Stanford Law School, UChicago, and Drake University Law Library research guides (all accessed June 2026); confirm against your own vendor's current docs before shipping.

The big trap: a bare space means OR on Westlaw but AND on Bloomberg Law, and on Lexis it depends on the other connectors present (UChicago Library guide, accessed June 2026). If you generate queries programmatically, never rely on the implicit space operator. Write the connector you mean.

Parentheses for Grouping

Combine operators with parentheses to build complex queries.

("Section 1983" OR "42 U.S.C. 1983") AND "color of law"

This finds civil-rights cases referencing the statute under either label, alongside the "under color of state law" element. Without parentheses, operator precedence could produce unexpected results.

Common Legal Search Patterns

Here are queries that practicing lawyers actually use. I've compiled these from watching how litigators interact with our search API over the past year.

These aren't toy examples. Each one maps to a real research task that a lawyer might spend 30 minutes doing manually.

A Worked Query, Refined Step by Step

Here is how one real search evolves. The task: find federal opinions where a court applied the APA's arbitrary-and-capricious standard to an agency action, after the Supreme Court ended Chevron deference.

Start broad. Two core terms, both quoted.

"arbitrary and capricious" AND "agency action"

That returns far too much: every administrative-law case touching the standard. Tighten it with proximity so the two ideas sit in the same sentence, which is where a court usually states the holding.

"arbitrary and capricious" /s "agency action"

Now add the post-Chevron angle and pin the title so the statute resolves cleanly.

("arbitrary and capricious" /s "agency action")
  AND "5 U.S.C. 706"
  AND ("Loper Bright" OR "Chevron" /5 overrul!)

Read it back: APA review provisions (5 U.S.C. 706), the standard stated in one sentence, and any opinion naming Loper Bright or discussing Chevron being overruled. The root expander overrul! catches overruled, overruling, and overrules in one term. That is a query you can save, version, and re-run next quarter with identical logic.

Using a Statutes Search API

Time for code. A typical hosted statutes API accepts Boolean queries at a POST /api/v1/statutes/search endpoint, across the U.S. Code, the CFR, federal rules, and all 50 state codes. You pass your query as a string, and the server parses the Boolean operators.

The same Boolean grammar usually carries over to the in-product case-law research surface, but case-law search is a product feature, not a public API endpoint.

Simple Search (Python)

import requests

url = "https://api.example.com/v1/statutes/search"
headers = {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json"
}

payload = {
    "query": '"civil action" AND "color of"'
}

response = requests.post(url, json=payload, headers=headers)
results = response.json()

for section in results["data"]["results"]:
    print(f"{section.get('title', '')} ({section['citation']})")
    print(f"  {section['snippet'][:200]}...")
    print()

Complex Query with Grouping

# Find sections touching either judicial review
# or the arbitrary-and-capricious standard
query = '"agency action" AND ("judicial review" OR "arbitrary and capricious")'

payload = {"query": query}
response = requests.post(url, json=payload, headers=headers)

data = response.json()
print(f"Found {len(data['data']['results'])} sections")

Scoping the Search

The statutes endpoint usually lets you narrow by code and jurisdiction so a bare section number resolves cleanly. An in-product case-law research surface applies the same idea on the opinion side, scoping by court level across the same three tiers: U.S. Supreme Court, the U.S. Courts of Appeals, and the U.S. District Courts.

# Federal statutes only
payload = {
    "query": '"arbitrary and capricious" AND "agency"',
    "filters": {
        "code": "usc",
    },
}

response = requests.post(url, json=payload, headers=headers)
data = response.json()

You can pair the code filter with a state jurisdiction to tighten the result set before any Boolean parsing even matters.

Handling Results and Pagination

def search_statutes(query, filters=None, page=1, page_size=20):
    """Search statutes with optional filters and pagination."""
    payload = {
        "query": query,
        "page": page,
        "pageSize": page_size,
    }
    if filters:
        payload["filters"] = filters

    response = requests.post(url, json=payload, headers=headers)
    response.raise_for_status()

    data = response.json()
    # meta contains total, page, pageSize, totalPages for pagination
    return data["data"]["results"]

# Example: APA review provisions in the U.S. Code
sections = search_statutes(
    '"arbitrary and capricious" AND "agency action"',
    filters={"code": "usc"},
)

for section in sections[:10]:
    print(f"{section.get('title', '')}")
    print(f"  {section['citation']}")

Create an API keyBook a demo

Building a Query Helper

For applications that let users construct queries through a UI, here's a simple helper:

def build_query(terms, exclude=None, operator="AND"):
    """Build a Boolean query from a list of terms.

    Args:
        terms: List of search terms (strings with spaces are auto-quoted)
        exclude: Optional list of terms to exclude
        operator: How to combine terms ("AND" or "OR")
    """
    parts = [f'"{t}"' if " " in t else t for t in terms]
    query = f" {operator} ".join(parts)

    if exclude:
        for term in exclude:
            quoted = f'"{term}"' if " " in term else term
            query += f" NOT {quoted}"

    return query

# Usage
q = build_query(
    ["18 U.S.C. 922", "felon in possession", "Second Amendment"],
    exclude=["sentencing guidelines"]
)
# Result: "18 U.S.C. 922" AND "felon in possession" AND "Second Amendment" NOT "sentencing guidelines"

print(search_statutes(q))

Boolean vs Semantic Search: When to Use Which

Boolean and semantic (AI / vector) search answer different questions, and the choice is about what you already know.

Boolean wins when you know the words. A citation, a statute number, a term of art like "qualified immunity." It matches exact tokens, so you get every hit and zero results you can't explain. The cost is that it misses documents that mean the same thing in different words: a search for "qualified immunity" will not surface an opinion that only says "good-faith defense for officials."

Semantic search wins when you know the concept but not the phrasing. It embeds your query and the documents as vectors and ranks by meaning, so "can police search my phone at the border" can return Fourth Amendment cases that never use those words. The cost is the opposite: ranked-by-similarity results are harder to audit, and there is no guarantee you saw everything.

We go deeper on the tradeoff in AI law search engine vs keyword search. The practical answer for most legal tech products is to use both.

Combining Boolean Search with AI

Boolean search and AI search aren't competing approaches. They're complementary.

We break down how the retrieval layer works in our post on how AI legal research actually works. Here's the workflow we recommend for developers building legal research tools:

Step 1: Use Boolean search via the statutes API to find the right statutory provisions. Boolean gives you precision and completeness. You know exactly why each result was returned.

Step 2: Pass the returned section text into your own LLM call (or into an in-product surface that adds case-law grounding) for synthesis with citations.

# Step 1: Boolean search for the operative provisions
search_results = search_statutes(
    '"civil action" AND "color of"',
    filters={"code": "usc"},
)

# Step 2: Hand the structured statute results to your own LLM
# layer for synthesis; the public API stops at retrieval.
for section in search_results:
    print(section["citation"], section["snippet"][:200])

This two-step approach gives you the best of both worlds: the recall and precision of Boolean search with the analytical power of an LLM you control.

Tips from Experience

A year of watching developers and lawyers use our search has taught me a few things.

US legal terminology is specific. "Qualified immunity" is a term of art. Searching for "government immunity" will miss most results, even though a layperson might use the phrases interchangeably.

Similarly, it's "fair use," not "permitted copying." If your queries aren't returning expected results, check that you're using standard US legal phrasing.

Citation formats are searchable. You can use citations directly in Boolean queries to find related results. For example, inside an in-product case-law research surface, "585 U.S. 296" finds Carpenter v. United States and every opinion that cites it by that reporter. This is a quick way to build a citation network around a landmark decision.

Proximity search finds legal tests. US courts love multi-factor tests. The Terry "reasonable suspicion" standard, the "arbitrary and capricious" standard of review, the transformative-use analysis.

These tests get discussed using specific but slightly varying language across opinions. A proximity query like "reasonable suspicion" /10 "stop and frisk" catches the variations that a phrase search would miss.

Start broad, then narrow. Begin with a simple two-term AND query. Look at how many results you get. If it's too many, add another AND term or a NOT clause. If it's too few, switch an AND to OR or use a wildcard. Think of it as iterative refinement, similar to debugging.

Quote everything that's multi-word. Forgetting to quote "reasonable suspicion" and searching for reasonable suspicion AND Terry will produce very different (and mostly wrong) results.

The unquoted words get treated as separate terms. This is the most common mistake I see developers make when constructing Boolean queries programmatically.

Common Mistakes in Boolean Query Construction

After a year of seeing how developers and lawyers build Boolean queries, I've catalogued the errors that come up repeatedly. Some of these cost hours of debugging. All of them are avoidable.

1. Forgetting to Quote Multi-Word Phrases

This is the single most common mistake. I mentioned it in the tips section, but it deserves its own callout because I see it in production code.

# Wrong: each word is treated as a separate term
query = "reasonable suspicion AND Fourth Amendment"

# Correct: the phrase is treated as a unit
query = '"reasonable suspicion" AND "Fourth Amendment"'

The unquoted version matches any document containing "reasonable" OR "suspicion" AND "Fourth" AND "Amendment" (depending on the implicit default operator). The results will be nearly useless.

When building queries programmatically, always wrap multi-word terms in escaped double quotes.

2. Getting Operator Precedence Wrong

Boolean operators have precedence rules, just like arithmetic. NOT binds tightest, then AND, then OR. This catches people off guard.

# What you wrote:
"bail" OR "anticipatory" AND "Supreme Court"

# What the engine evaluates (AND before OR):
"bail" OR ("anticipatory" AND "Supreme Court")

# What you probably meant:
("bail" OR "anticipatory") AND "Supreme Court"

Here's the same trap with US criminal-procedure terms:

# What you wrote:
"Miranda" OR "Terry" AND "suppression"

# What the engine evaluates (AND before OR):
"Miranda" OR ("Terry" AND "suppression")

# What you probably meant:
("Miranda" OR "Terry") AND "suppression"

Always use parentheses when combining AND and OR in the same query. It makes your intent explicit and prevents subtle bugs.

3. Over-Constraining with AND

New users tend to stack too many AND terms in a single query, then wonder why they get zero results.

# Too many constraints: likely returns nothing
"qualified immunity" AND "excessive force" AND "Ninth Circuit" AND "2023" AND "summary judgment" AND "K-9"

# Better: start broad, filter in code
"qualified immunity" AND "excessive force" AND "summary judgment"

Start with two or three core terms. If you get too many results, add one more constraint at a time. It's easier to narrow a broad search than to figure out which of six AND terms is excluding the case you need. (Court and year are better expressed as filters, not stacked AND terms.)

4. Using NOT Too Aggressively

NOT removes every document containing the excluded term, even if it appears in a footnote or a passing reference. This means you can accidentally exclude highly relevant cases.

# Dangerous: removes any case that mentions "parody" anywhere
"fair use" NOT "parody"

# Safer: combine with more specific phrasing
"fair use" AND "transformative" NOT "parody defense"

Use NOT with specific phrases rather than single words. And if you're filtering in application code, consider doing the exclusion post-retrieval where you can inspect the context around the excluded term.

5. Mixing Up Section Numbers Across Statutes

US law has many statutes with identical section numbers. A bare "Section 1983" reads to a human as the civil-rights statute, but "Section 7" or "Section 706" could belong to any number of titles.

The fix is to pin the title. 5 U.S.C. § 706 is APA review; a freestanding "706" is meaningless to a search engine.

# Ambiguous
"Section 706" AND "review"

# Unambiguous
"5 U.S.C. 706" AND "arbitrary and capricious"

Always pair section numbers with the title or statute name. This is one area where Boolean search is more demanding than AI search, which can sometimes infer the statute from context.

6. Not Accounting for Citation Format Variations

If you're searching for cases that cite a specific judgment, remember that the same case has multiple reporters. Carpenter v. United States appears as 585 U.S. 296, 138 S. Ct. 2206, and 201 L. Ed. 2d 507. Searching for just one reporter misses references using any of the others.

# Only catches one reporter
"585 U.S. 296"

# Catches more references (but still not all)
"585 U.S. 296" OR "138 S. Ct. 2206" OR "201 L. Ed. 2d 507"

Lower-court cites add F.2d/F.3d (the Federal Reporter) and F. Supp. (Federal Supplement) to the mix.

For comprehensive citation-based searching, it's better to first resolve all aliases for a case, then construct an OR query across all known formats.

7. Ignoring Wildcard Limitations

Wildcards are powerful, but they only work at the end of a term. Mid-word or leading wildcards are not supported.

# Works: matches negligence, negligent, negligently
neglig*

# Does NOT work: leading wildcard
*ligence

# Does NOT work: mid-word wildcard
neg*ence

If you need to match word variations that don't share a common prefix, use OR instead: "negligence" OR "negligent" OR "negligently".

One More Pattern: "Is It Still Good Law?"

Boolean search is also how you catch a precedent that has been pulled out from under you.

The cleanest example in recent memory is Chevron U.S.A. v. NRDC, 467 U.S. 837 (1984), which set the deference standard for decades and was then overruled by Loper Bright Enterprises v. Raimondo, 603 U.S. 369 (2024).

# Surface every opinion flagging Chevron's status
Chevron AND ("overruled" OR "abrogated" OR "no longer good law")

Run that inside an in-product case-law surface before you cite Chevron deference in a brief, and you'll find the cases that bury it.

The narrative (opinions discussing the overruling) plus the citator's status flag gives you both the discussion and the machine-readable signal in one place.

What a Statutes Search API Ships

The piece that usually ships as a public API is statutes-only: Boolean queries across the U.S. Code, the CFR, federal rules, and all 50 state codes, returning structured JSON with consistent fields (citation strings, titles, scores, and highlighted snippets).

Authentication, rate limiting, and versioning are documented at the cleaner vendors, so production applications can build on it directly.

FAQ

What is Boolean search in legal research?

Boolean search (also called terms and connectors searching) is a method of querying a legal database by combining keywords with logical operators: AND, OR, NOT, exact phrases in quotes, proximity connectors, and wildcards. It is named after the mathematician George Boole. Unlike natural-language search, it returns every document that matches your exact logic, with no ranking guesswork.

What are the three Boolean operators?

AND, OR, and NOT. AND narrows a search by requiring all terms to appear. OR broadens it by accepting any of the terms, which is useful for synonyms. NOT excludes documents containing a term. Most legal platforms add proximity operators and a root expander on top of these three.

How does proximity search work in Westlaw and Lexis?

Use /n to require two terms within n words of each other, /s for the same sentence, and /p for the same paragraph. So "reasonable suspicion" /s Terry keeps both terms in one sentence. On Lexis, /p is processed as within 75 words and /s as within 25 words (Stanford Law School guide, accessed June 2026).

What is the difference between Westlaw and Lexis connectors?

The core grammar is the same, but symbols drift. Westlaw excludes with % or BUT NOT and treats a bare space as OR; Lexis excludes with AND NOT. The single-character wildcard is * on Westlaw and ? on Lexis, where * instead behaves like the root expander. Always confirm against the platform's current docs.

Can you use Boolean search in free legal databases?

Yes. Many free and hosted tools support keyword and phrase queries over US opinions, and many hosted statutes APIs parse Boolean operators server-side. These tools often support AND, OR, NOT, quotes, and a trailing-* root expander, but proximity operators like /s and /p are frequently unsupported, so test before relying on them.

Is Boolean search better than AI legal search?

Neither is strictly better; they solve different problems. Boolean wins when you know the exact term, citation, or statute and need complete, auditable results. AI or semantic search wins when you know the concept but not the wording. The strongest legal research workflows use Boolean to retrieve and an LLM layer to synthesize. See AI law search engine vs keyword search.

What is a root expander in legal search?

The root expander (! on Westlaw, Lexis, and Bloomberg Law) matches a word root plus any number of trailing characters. For example, overrul! matches overruled, overruling, and overrules in a single term. It saves you from writing every variation as a long OR chain.

Why do my Boolean queries return zero results?

The usual causes are over-stacking AND terms, mixing AND and OR without parentheses so precedence drops half your hits, an over-aggressive NOT that excludes relevant cases, or an unquoted multi-word phrase that splits into separate terms. Start with two or three core terms, then narrow one step at a time.

A closing takeaway

If you're building anything that touches US law (legal research tool, compliance checker, contract analysis platform, litigation management system), Boolean search over a structured statutes API is the fastest way to add reliable statute lookup.

The same statutes corpus a Boolean query hits through the API: US Code, CFR, federal rules, and all 50 state codes.

Vaquill AI exposes exactly this: a hosted statutes API that parses Boolean queries across the US Code, the CFR, federal rules, and all 50 state codes, returning structured JSON you can hand straight to your own LLM layer. If you want to try the Boolean grammar in this guide against a live statutes corpus, see /legal-api, or email contact@vaquill.ai.

For related developer coverage, see How AI Legal Research Works (RAG) and Pulling US Code and Statutes Programmatically.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.