Boolean Search Operators for Literature Searching

A systematic or scoping review lives or dies on its search strategy. The Boolean operators AND, OR, and NOT are the mechanism that turns a research question into a reproducible, reportable set of database queries — but the same three-letter words behave differently depending on how they’re nested, which symbols a database uses for truncation and proximity, and whether a term is searched as free text or mapped to a controlled vocabulary. This guide works through the operators themselves, the syntax differences between major databases, how to build a search from a structured question like PICO, and how to document the search so it can be reported and reproduced.

Because search syntax genuinely differs by platform — and an invented symbol in a published search strategy is a real, citable error — this guide states what is common across databases and flags, explicitly, where you need to confirm the exact syntax against that database’s own help documentation before running or publishing a search.

The three core operators: AND, OR, NOT

Boolean logic in a database search combines search terms into a single query. The three operators do three different jobs, and confusing “broadens” with “narrows” is the single most common point of confusion for new searchers.

• OR broadens. diabetes OR "diabetes mellitus" retrieves any record containing either term — the result set is the union of both searches, so it is always equal to or larger than either term searched alone. OR is how you combine synonyms, spelling variants, and related terms that all describe the same concept.
• AND narrows. diabetes AND metformin retrieves only records containing both terms — the result set is the intersection, so it is always equal to or smaller than either term searched alone. AND is how you combine separate concepts (population, intervention, outcome) so the search reflects the actual research question rather than any one component of it.
• NOT excludes. diabetes NOT "gestational diabetes" removes records containing the excluded term — but it removes them even if they are also highly relevant to the rest of the search. NOT is the most dangerous of the three operators because it discards records on the basis of a single word appearing anywhere the search checks, with no regard for context; a record about type 2 diabetes that happens to mention gestational diabetes in passing (a common comorbidity discussion, a differential-diagnosis note) is silently dropped along with the ones you actually meant to exclude.

A useful mental model: OR adds rows to a spreadsheet of results; AND deletes rows that don’t satisfy every column; NOT deletes rows that match a condition you’ve flagged as disqualifying, without checking whether they also satisfy everything else.

Nesting with parentheses and operator precedence

Real search strategies almost always combine all three operators in one query, and that requires parentheses to group terms into concept blocks — synonyms for one idea joined with OR inside the parentheses, then those blocks joined with AND between them.

Precedence matters because an unparenthesized mix of AND and OR is genuinely ambiguous, and different systems can resolve that ambiguity differently — some evaluate AND before OR (comparable to multiplication before addition in arithmetic), others evaluate strictly left to right. A query like:

cats AND dogs OR rabbits

can be interpreted as (cats AND dogs) OR rabbits — which would return every record about rabbits, whether or not it mentions cats or dogs at all, plus records that mention both cats and dogs. That is very unlikely to be what the searcher intended (probably “cats AND (dogs OR rabbits)”), but the query as written doesn’t say which reading applies, and it silently returns whichever set the database’s default precedence rule produces. This is exactly the kind of error that is invisible unless you scan the actual result count and a sample of results — the search runs without any error message either way.

The fix is not to learn each database’s precedence rule and rely on it — it’s to never leave the ambiguity in the query at all:

(diabetes OR "diabetes mellitus") AND (metformin OR biguanide*)

Always group each OR’d synonym set in its own parentheses, and never mix AND and OR inside the same set of parentheses without an inner grouping. This is the single highest-value habit for building a search strategy that returns what you actually designed it to return.

Phrase searching, truncation, and wildcards

Beyond the three logical operators, most databases support ways to control how literally a term is matched:

• Phrase searching — wrapping multiple words in quotation marks ("randomized controlled trial") tells the database to match that exact sequence of words rather than treating each word as a separate, independently-matched term.
• Truncation — a symbol appended to a word’s root to match multiple endings in one term, so a single truncated term stands in for an OR’d list of variants. In PubMed, the asterisk (*) truncates the end of a word — nurs* matches nurse, nurses, and nursing — but PubMed requires a minimum root length of four characters before the asterisk and only allows truncation of the last word in a phrase, per NLM’s own PubMed Help documentation.
• Wildcards — a symbol that substitutes for a single character or an optional character within a word, useful for spelling variants such as UK/US English (randomised/randomized) or plural forms with an internal change (woman/women).

The exact symbols are not consistent across databases, and some symbols mean different things on different platforms even when they look identical. This is not a minor footnote — it is one of the most commonly documented sources of search error in the health-sciences librarian literature on cross-database translation. As one worked comparison puts it: a proximity expression that behaves one way in Web of Science can specify a different word-distance in Embase even though it’s written with the same operator name, and a wildcard symbol can mean “zero or one character” on one vendor’s interface and “an unlimited number of characters” on another vendor’s interface for the exact same database’s content, depending on which platform (e.g., Ovid’s interface to Embase versus Elsevier’s own Embase.com interface) you’re searching through. Do not assume a symbol carries over from one database — or even one interface to the same database — to another. Confirm the current truncation and wildcard symbols in that specific platform’s own help pages before running or publishing a search string.

Proximity operators: NEAR, ADJ, W/N

Proximity operators require two terms to appear within a specified distance of each other, which is tighter than AND (any distance, anywhere in the record) but looser than phrase searching (exact adjacent sequence). They are especially useful for concepts commonly expressed as a modifier-plus-noun pair that isn’t always written as a fixed phrase.

The operator name, the syntax, and even what the number means differ by platform:

• Web of Science uses NEAR/n (terms within n additional words of each other, order not fixed) and a separate SAME operator (terms within the same sentence).
• Embase via Ovid uses ADJn (terms within n words of each other, in any order) — and, per published cross-database comparisons, the same numeric value in NEAR/n on Web of Science and ADJn on Ovid Embase does not necessarily specify the same word-distance, because the two platforms define the counted interval differently.
• EBSCO platforms (e.g., CINAHL, PsycINFO via EBSCOhost) generally use Wn (within n words, in the order entered) and Nn (within n words, order not fixed).

Not every database supports proximity searching at all, and not every subscription tier of a given platform exposes it the same way. Treat every number and every operator letter here as something to re-confirm against the specific platform’s current help documentation immediately before use — this is exactly the kind of detail that changes between platforms and even between interface versions of the same database, and getting it wrong doesn’t produce an error, it produces a silently wrong result set.

Field tags and controlled vocabulary

A term typed into a database search box can be searched two different ways: as free text (matched literally against whatever words appear in a record, usually restricted to a specific field with a field tag) or via controlled vocabulary (matched against a standardized subject heading that a human indexer has already assigned to that record, regardless of the exact words the original authors used).

• Field tags restrict a free-text search to a specific part of the record. PubMed’s [tiab] tag, for example, restricts a search to the title and abstract fields only, rather than the full indexed record — commonly combined with truncation and phrase searching for precise free-text searching. Databases also typically support tags for publication type and for date-range limits, though the exact tag syntax and available limits vary by platform.
• Controlled vocabulary differs by database, because each major database maintains its own thesaurus: PubMed/MEDLINE uses the U.S. National Library of Medicine’s MeSH (Medical Subject Headings); Embase uses Elsevier’s Emtree; CINAHL uses its own CINAHL Subject Headings; and APA’s PsycINFO uses the APA Thesaurus of Psychological Index Terms. These vocabularies overlap substantially in coverage but are not identical term-for-term, which is a core reason a search strategy has to be rebuilt, not just copy-pasted, when moving to a different database.
• Explosion automatically includes a heading’s narrower, more specific subordinate terms in the search (searching the broad MeSH term for a condition and automatically picking up its more specific sub-types), and is normally the default behavior for a MeSH search in PubMed.
• Focus (sometimes called a “major topic” or “major concept” restriction) limits results to records where the controlled-vocabulary heading was indexed as a central topic of the article rather than a passing mention — a precision tool for when a broad heading search is returning too many marginally relevant results.

A well-built systematic-review search strategy generally combines both: a free-text block (synonyms, spelling variants, truncation, field tags) OR’d together with the matching controlled-vocabulary term(s), because relying on controlled vocabulary alone misses recently published records that haven’t been indexed yet, and relying on free text alone misses records where the authors used different terminology than your search anticipated.

Building a search from a structured question (PICO)

A structured question framework — PICO (Population, Intervention, Comparison, Outcome) for quantitative and clinical questions, or its variants PICo (Population, Interest, Context) and SPIDER (Sample, Phenomenon of Interest, Design, Evaluation, Research type) for qualitative questions — translates directly into a search strategy: each element of the framework becomes one concept block, synonyms within a block are joined with OR, and the blocks are joined with AND.

Illustrative example (a worked construction to show the technique, not a validated, published search hedge — always have any real search strategy checked before it goes into a protocol):

Research question: In adults with type 2 diabetes, does metformin compared with a sulfonylurea reduce the incidence of major cardiovascular events?

("type 2 diabetes"[tiab] OR "type 2 diabetes mellitus"[tiab] OR T2DM[tiab] OR NIDDM[tiab] OR "diabetes mellitus, type 2"[mh])
AND
(metformin[tiab] OR metformin[mh] OR biguanide*[tiab])
AND
(sulfonylurea*[tiab] OR glyburide[tiab] OR gliclazide[tiab] OR glipizide[tiab] OR "sulfonylurea compounds"[mh])
AND
("myocardial infarction"[tiab] OR stroke[tiab] OR "cardiovascular diseases"[mh] OR "cardiovascular mortality"[tiab] OR "major adverse cardiovascular events"[tiab])

Each parenthesized block corresponds to one PICO element (population, intervention, comparator, outcome); OR combines the synonyms and free-text/MeSH pairing within a block; AND combines the four blocks. This is written in PubMed-style field-tag syntax as an illustration of the structure — the field tags, truncation symbol, and MeSH heading names would all need to be re-verified and rebuilt for any other database, per the translation section below.

Translating a search across databases

A finished PubMed strategy cannot be copy-pasted into Embase, Web of Science, or CINAHL and re-run as-is. Field tags don’t exist on other platforms in the same form, MeSH headings have to be re-mapped to that database’s own controlled vocabulary (Emtree, CINAHL headings, and so on) rather than assumed to be identical, and truncation/wildcard/proximity symbols carry different meanings — sometimes no meaning at all — on a different platform. The Cochrane Handbook goes further for Cochrane reviews specifically, treating it as close to mandatory that a review searches more than one major bibliographic database (typically at minimum CENTRAL, MEDLINE, and Embase) precisely because no single database has complete coverage, which makes translation a routine, expected part of a real search strategy rather than an edge case.

CASRAI’s PubMed-to-Embase Search Strategy Translation guide walks through this specific translation line by line, including the MeSH-to-Emtree vocabulary mapping and the syntax substitutions involved — read it alongside this page if PubMed and Embase are both in your search plan.

Documenting and reporting the search

A systematic review’s search has to be reproducible: another researcher, given the same strategy and the same run date, should be able to obtain essentially the same result set (allowing for ongoing indexing since the original search date). That means recording, for every database searched:

• The complete, exact search string as run — not a paraphrase or summary of the search logic.
• The database and the specific platform/interface used (e.g., MEDLINE via PubMed versus MEDLINE via Ovid are not interchangeable for reporting purposes, since the interface affects available syntax).
• The date the search was run, since bibliographic databases are continuously updated.
• The number of results (“hits”) returned per database.
• Any limits or filters applied (date range, language, publication type) and, if a pre-built search filter or “hedge” was used, whether it was independently validated.

PRISMA-S is the dedicated PRISMA extension for reporting exactly this: a 2021 16-item checklist, developed by information specialists through a Delphi/consensus process and published alongside explanation and elaboration for each item, that specifies what a systematic review’s methods and supplementary materials need to report about the literature search itself — separate from, and more detailed than, the general PRISMA 2020 checklist’s search-related items. See CASRAI’s PRISMA and systematic review methodology guide and the PRISMA 2020 dictionary entry for how search reporting fits into the wider checklist.

After running searches across multiple databases, the combined result set will contain duplicate records — the same article indexed in more than one database. Deduplication (removing these before screening begins) is a standard, expected step between running the search and starting title/abstract screening, and is itself something PRISMA-S expects to see reported (how deduplication was done, and by what method or software).

Common failure modes

• Over-restriction with NOT. Using NOT to exclude an unwanted sense of an ambiguous term (or an unrelated topic that happens to share a keyword) routinely discards relevant records too, because NOT has no way to check whether the excluded term appears in a relevant context. A more targeted alternative — restricting the excluded term to a specific field with a field tag, or excluding at the screening stage instead of the search stage — is usually safer than a blanket NOT.
• Missing synonyms and spelling variants. UK/US spelling differences (randomised/randomized, tumour/tumor), abbreviations, brand names versus generic names, and older terminology that’s since fallen out of use are all common gaps. A synonym list built by only one reviewer, without input from a second reviewer or an information specialist, is a common source of a search that’s missing a real concept-relevant term entirely.
• Forgetting truncation. Searching randomize without a truncation symbol misses randomized, randomizing, and randomization — each of which would need to be entered individually and OR’d together if truncation isn’t used.
• Over-reliance on a single database. No single database has complete coverage of the relevant literature for most topics; searching only PubMed (or only Google Scholar) is one of the most common and most consequential shortcuts a review search takes, and it’s exactly what multi-database Cochrane-style requirements and PRISMA-S reporting are designed to make visible and discourage.
• Using an unvalidated filter or “hedge.” Pre-built search filters (for study design, for example) that haven’t been independently validated for sensitivity and specificity can silently distort a review’s coverage; treat a borrowed filter as something to check the validation evidence for, not something to assume works as advertised.

Frequently asked questions

Does OR broaden or narrow a search?

OR broadens. It returns every record that matches at least one of the OR’d terms, so the result set is always at least as large as any single term searched alone. AND is the operator that narrows, by requiring every joined term to be present.

Can I reuse the same Boolean search string in PubMed and Embase?

No, not unedited. Field tags, controlled-vocabulary term names (MeSH versus Emtree), and truncation/proximity symbols all differ between the two systems. See the PubMed-to-Embase translation guide for the specific mapping.

What’s the difference between a field tag and controlled vocabulary?

A field tag (like PubMed’s [tiab]) restricts a free-text search to a specific part of the record, such as title and abstract. Controlled vocabulary (like MeSH or Emtree) is a standardized subject heading assigned by an indexer, independent of the exact wording the original authors used — the two are typically combined, not used as alternatives to each other.

Why does my search need parentheses if I’m only using AND and OR?

Because a mix of AND and OR without parentheses is ambiguous, and different database systems can resolve that ambiguity differently by default. Explicit parentheses around every OR’d synonym set remove the ambiguity regardless of which default a given platform applies.

What should I report about my search strategy in a systematic review?

At minimum, per PRISMA-S: the complete search string for each database, the platform/interface used, the date the search was run, the number of hits per database, any limits applied, and how deduplication was handled.