The PubMed Advanced Search Builder: Numbered History, Field Tags, and Reading Search Details

The Advanced Search page is where a PubMed search stops being a box you type into and becomes a strategy you can report. The Builder, the numbered History, and the Search Details expander are three tools that do three different jobs, and the third one is the job almost nobody does: reading back what PubMed actually ran.

That matters because the query PubMed runs is routinely not the query you typed. It expands your words through Automatic Term Mapping, it silently binds a field tag to only part of your line, it processes your Boolean operators strictly left to right, and it will discard an unrecognised tag rather than refuse the search. Every one of those changes the number at the end of the row, and every one of them is invisible unless you expand Search Details. This page sets out what NLM documents about each Builder and History mechanic, and pairs it with retrieval counts measured directly against PubMed so you can see the size of each effect rather than take it on faith.

How to read this page

Three tiers, kept separate throughout, in the same way as CASRAI’s companion pages on MeSH mechanics in PubMed and on which Google Scholar operators actually work:

1. Documented — stated by NLM in the PubMed User Guide, the authoritative specification for PubMed’s query syntax and for the Advanced Search page itself.
2. Measured — a retrieval count obtained by running the query through PubMed’s E-utilities esearch API on 26 August 2026. PubMed grows daily, so every count here is a snapshot; the ratios are the durable finding.
3. Observed only — reproducible behaviour NLM has not specified in writing, flagged as such rather than presented as a rule.

One important limit on the measurements. E-utilities and the web interface share PubMed’s query engine and its translation output, but they are not the same client. Anything below that concerns what appears on screen — a red warning banner, an autocomplete list, what the Add button writes into the Query box — is reported from NLM’s documentation, not from our own observation, and is labelled that way. Where the API and the documented web behaviour diverge, we say so instead of smoothing it over.

What the Advanced Search page is actually for

Documented. NLM describes the tools on the Advanced Search page as helping users to "search for terms in a specific field, combine searches and build large, complex search strings, see how each query was translated by PubMed, and compare number of results for different queries." Those are four distinct jobs, and it is worth naming them separately because most tutorials only cover the first:

Tool	What it does	When you need it
Builder	Field drop-down plus a term box; adds tagged terms into the Query box, joined by AND, OR or NOT.	Composing a line without memorising tag syntax.
Show Index	Alphabetical browse of the terms actually present in a chosen field, with approximate counts.	Finding out what strings exist to be matched, before you guess one.
Add to History	Runs the query without leaving the page and records it as a numbered line.	Comparing counts across variants; building a set to combine later.
Search Details	Expands a History row to show the translation PubMed used, plus any warnings.	Every single time. This is the only place the executed query is visible.

The Builder: what it does and what it does not protect you from

Documented. From the "All Fields" drop-down you select a field, type a term, and add it to the Query box; NLM notes that "for some fields, an autocomplete feature will provide suggestions as you type," and that "the default Boolean operator is AND; if desired, choose OR or NOT from the pull-down menu." You then click Search, or use the split button to switch it to Add to History, which runs the query without navigating away.

Show Index is the underused half. It "provides an alphabetical display of terms appearing in selected PubMed search fields," with "the approximate number of citations for each term (the actual citation count is returned when the search is executed)." Multiple terms can be selected at once, and — this is the one place the Builder actively saves you from yourself — NLM documents that "the builder will automatically OR (and add parentheses) for multiple terms selected from the index." Show Index is not available for every field, and not for date fields at all.

The trap: PubMed processes Boolean operators left to right

Documented, and stated twice in the User Guide: "PubMed processes searches in a left-to-right sequence. Use parentheses to nest concepts that should be processed as a unit." This is not how most people read a Boolean expression, and it is not how most other databases behave — conventional precedence binds AND more tightly than OR. In PubMed there is no precedence at all: whatever is on the left is resolved first.

The consequence is asymmetric, which is why it is so easy to miss. A OR B AND C is safe by accident, because left-to-right and conventional precedence happen to agree on it. A AND B OR C is not.

Measured, 26 August 2026:

Query	Records	What PubMed actually ran
hypertension AND diet OR exercise	716,426	(hypertension AND diet) OR exercise
hypertension AND (diet OR exercise)	58,675	The search you meant.
hypertension AND diet	34,109	For scale.
exercise	686,500	For scale.

A 12.2-fold inflation from one missing pair of parentheses. And note what the unparenthesised set is made of: 686,500 of the 716,426 records are simply everything about exercise. The hypertension concept has effectively been deleted from the search, and the result set still looks entirely plausible — it is large, it is on-topic, it ranks sensibly. Nothing on the results page says anything is wrong.

By contrast, measured the same day, "myocardial infarction"[mh] OR "stroke"[mh] AND aspirin[tiab] and its parenthesised form both returned 7,787, and Search Details returned the identical translation for both, with PubMed supplying the parentheses itself: ("myocardial infarction"[MeSH Terms] OR "stroke"[MeSH Terms]) AND "aspirin"[Title/Abstract]. That is left-to-right doing exactly what you wanted, purely by luck of operator order. Do not learn the wrong lesson from it: parenthesise every concept group, every time, and confirm in Search Details that the brackets survived.

Field tags in the Builder: what the tag binds to

Documented. The Builder writes a search field tag after your term, and NLM is explicit about three properties that between them cause most silent field-tag failures:

• "Search field tags turn off Automatic Term Mapping, limiting your search to the specified term only."
• "Using a search field tag after multiple terms will attempt to search those terms as a phrase."
• "To search multiple terms in the same field, each term must be tagged individually." NLM’s own example is covid-19[ti] vaccine[ti] children[ti].
• Case and spacing do not matter: crabs [mh] is the same search as Crabs[mh]. Measured: both returned 8,444.

The second and third properties fight each other, and the direction of the error flips depending on which one bites. Measured, 26 August 2026:

Query	Records	What the tag actually bound to
kidney allograft[tiab]	4,059	The whole thing, as the phrase "kidney allograft"[Title/Abstract].
kidney[tiab] AND allograft[tiab]	15,499	Two independent terms. 3.8× more.
covid-19 vaccine children[ti]	1,632	Only "children"[Title]. The rest went through ATM across all fields.
covid-19[ti] vaccine[ti] children[ti]	331	All three in the title. 4.9× fewer.

Both rows are wrong in ways that look right. The first pair loses two-thirds of the relevant literature because a phrase index match is much narrower than a co-occurrence; the second pair inflates fivefold because the tag only reached the last word and the first two silently escaped into an all-fields search. Search Details shows the difference immediately: the third query’s translation begins with an ATM expansion of COVID-19 Vaccines across [All Fields], which is not what anyone typing [ti] intended.

An unrecognised field tag does not fail loudly

Documented for the web interface: Search Details includes a Warnings section, and "warnings are displayed for the original query with potential errors in bold and red type, such as syntax errors, terms not found, or invalid tags. Warnings also appear as a highlighted message in PubMed when the search is run or added to History."

Observed only, and the reason we flag it: through the E-utilities API on 26 August 2026 that warning does not arrive, and the tag is simply discarded. sepsis[abstract] and sepsis[zzz] both returned 249,546 — identical to an untagged sepsis, translated as "sepsis"[MeSH Terms] OR "sepsis"[All Fields] — against 150,862 for the correct sepsis[tiab]. The API’s fieldsnotfound list came back empty in both cases. So an invalid tag does not narrow your search and does not zero it; it widens it by about 99,000 records while leaving a line in your strategy that reads as though it were field-limited.

There is no [abstract] tag. The Title/Abstract field is [tiab], and there are only about fifty valid tags in total — the full list is in the User Guide. If you are hand-editing the Query box rather than letting the Builder’s drop-down write the tag, check the translation afterwards, because the tag you invented will not announce itself.

Quoting inside the Query box

CASRAI’s MeSH page covers what quoting does to a tagged term — most sharply, that "heart attack"[mh] returns zero while heart attack[mh] returns 206,603, because quoting suppresses the entry-term mapping. The Builder-side question is the untagged one, and it has a different shape.

Documented: "When you enter search terms as a phrase, PubMed will not perform automatic term mapping." Measured, 26 August 2026:

Query	Records	Reading
heart attack	330,542	ATM builds the hedge: Myocardial Infarction[MeSH] OR the phrase OR the two words.
"heart attack"	6,153	Phrase index only. 54× fewer.
"heart attack*"	7,872	Wildcard also disables ATM; slightly broader than the bare phrase, still 42× short.

Quoting a lay synonym to be "more precise" discards the controlled-vocabulary half of the search entirely. That is the correct behaviour when you genuinely want a literal string and the wrong behaviour almost every other time.

When a quoted phrase is not in the phrase index

Documented. PubMed matches quoted strings against a phrase index, and "phrases may appear in a PubMed record but not be in the phrase index." When that happens the search returns nothing at all. NLM’s documented fix is a proximity search with a distance of zero.

Measured, 26 August 2026, using NLM’s own example phrase:

Query	Records
"cognitive impairment in multiple sclerosis"[tiab]	0 — API returned a quotedphrasesnotfound warning
"cognitive impairment in multiple sclerosis"[tiab:~0]	310

The warning object the API returned is the same information the web interface renders as a red Warnings line under Search Details. A zero-result row in your History is therefore not always evidence of absence — sometimes it is evidence that your phrase was never indexed as a phrase. Expand the row before you conclude a concept has no literature.

Proximity searching is the general form of that fix, and it is Builder-adjacent because the syntax is not offered by the drop-down — you type it. Format: "search terms"[field:~N], where N is the maximum number of words allowed between your terms, results come back in any order, and the feature is available only in [ti], [tiab] and [ad]. Measured on NLM’s example:

Query	Records
"rationing healthcare"[ti]	15
"rationing healthcare"[ti:~0]	60
"rationing healthcare"[ti:~2]	81

Four times the yield from N=0 alone, because adjacency in any order catches "healthcare rationing" as well as "rationing healthcare". Note the documented incompatibility: proximity does not work with wildcards, and if the quoted terms contain an asterisk "the proximity operator will be ignored" — silently, again.

Search History: the numbered workflow

Documented. History lives on the Advanced Search page and requires cookies. The rules that govern it are specific enough to matter for anyone building a strategy over more than one sitting:

• "Searches are numbered in chronological order. Search numbers may be used in place of the search string itself when combining queries (e.g., #1 OR #2)."
• "A repeated query will move to the top of History but will retain its original numbering."
• "History is limited to the last 100 searches." Beyond that, PubMed drops the oldest.
• History expires after 8 hours of inactivity. This is the one that costs people a day’s work.
• Clipboard citations are addressable as #0 — NLM’s example, #0 AND english[la], limits your clipboard to English-language records without changing the clipboard.
• Each row carries a Download option producing a CSV of the current History items.

The intended loop is: build a line in the Builder, Add to History rather than Search, read the count, expand the details, fix what is wrong, and only then combine. NLM’s documented combining route is the More Actions ("…") icon on a History row, then Add query, which copies that query into the Query box; the AND / OR / NOT options appear once there is something in the box to combine with.

What a history reference actually resolves to

Measured, 26 August 2026. E-utilities exposes an equivalent numbered-history mechanism through usehistory=y, and it resolves #n references the same way. Running hypertension[mh] (340,893 records) as #1, exercise[mh] (291,264) as #2, then #1 AND #2, returned 5,913 — and the translation came back as "hypertension"[MeSH Terms] AND "exercise"[MeSH Terms].

That translation is the point. The history number is not an opaque handle to a frozen result set; it expands back into the query text, and Search Details on the combined row shows you the full expanded strategy rather than #1 AND #2. This is precisely why a PubMed strategy is reportable at all: the numbered lines are a shorthand for a single flat Boolean expression that can be printed, re-run and audited by someone who was not there.

Reading Search Details — the habit that makes a strategy defensible

Documented. Click the chevron (">") next to a History row and the expanded details "show the search strategy used to run the search." Two sub-sections:

• Translations — "individual term mappings using PubMed’s search rules and syntax. Query terms without translations will not be listed in this section; for example, exact phrases bypass Automatic Term Mapping." A term missing from Translations is therefore itself a signal: it means that term went in raw.
• Warnings — syntax errors, terms not found, invalid tags, shown in bold red against the original query.

NLM lists what PubMed may add on your behalf: "MeSH terms, British/American spellings, singular/plural word forms, and other synonyms." Two measured examples show why you cannot predict this from the outside.

Measured: a term that maps to two unrelated concepts. crabs[mh] returned 8,444 records, translated as "phthirus"[MeSH Terms] OR "brachyura"[MeSH Terms] — pubic lice and the crustaceans. Both are legitimate MeSH mappings of the entry term. If you were searching for one, you have silently retrieved the other, and the only place that is visible is the translation line.

Measured: automatic phrase parsing. NLM documents that for air bladder fistula, PubMed "will search air bladder as a phrase," and that entering air AND bladder AND fistula avoids it. The counts are nearly identical — 71 versus 70 — but the translations are not remotely the same: the first resolves "air bladder" to Air Sacs[MeSH], a fish anatomy heading; the second resolves "bladder" to Urinary Bladder[MeSH]. Two searches, the same size, retrieving on entirely different concepts. A count comparison would have told you nothing. The translation tells you everything.

The reporting minimum

For a search whose strategy has to appear in a protocol, a methods section or a PRISMA-style flow, four things need to travel together per line, and the History table supplies all four: the query as run (the Query column), how PubMed translated it (Search Details), the number of records (Results), and the date and time (Time). The Download CSV captures the set in one file. One practical warning from NLM: Excel "is typically unable to display or print more than a maximum of 1024 characters in a cell," and a fully expanded PubMed translation runs well past that — open the CSV in a text editor if you want your complete strategy back.

Copy the translated strategy, not just what you typed. A reviewer who re-runs your typed line in a year gets whatever ATM does then; a reviewer who re-runs the translation gets what you actually searched. Where the two differ materially — and everything above is a catalogue of ways they differ — the translation is the record.

A ten-minute Builder routine

1. One concept per line. Build each concept separately in the Builder and Add to History, so each gets its own number, count and translation.
2. Expand every row before you use it. Check the Translations block for terms you did not expect and for terms that are missing (which means they bypassed ATM). Check for a Warnings line.
3. Tag every term individually if you are field-limiting, and confirm in the translation that each one carries the field, not just the last one.
4. Parenthesise every group, then confirm the brackets are still there in the translation. Left-to-right processing does not warn you.
5. Treat any zero-result row as suspect until you have checked whether the phrase is simply absent from the phrase index; try [tiab:~0].
6. Combine by number (#1 AND #2), and read the combined row’s translation to confirm the whole expression is what you meant.
7. Download the CSV before you leave — History is gone after 8 hours of inactivity, and a 100-search cap will start dropping your earliest lines on a long build.

Where this fits in a search strategy

This page is the interface-and-workflow half of PubMed searching; its companion, CASRAI’s page on MeSH terms in PubMed, is the vocabulary half — explosion, [majr], subheadings, and why a MeSH-only strategy under-retrieves the recent literature. The Builder can only build what the vocabulary supports, and Search Details is where you find out which of the two just failed you.

Beyond PubMed: the underlying grammar is covered in Boolean search operators for literature searching; Google Scholar’s advanced search operators are the opposite trade-off, enormous reach with almost no query language; and every database boundary you cross costs you a translation — see PubMed-to-Embase strategy translation, searching Web of Science effectively, and the ERIC database for education literature. Structure the question first with PICO or a PICOT question, cover what no database indexes with a grey-literature search, and screen the results in Covidence, Rayyan or DistillerSR. For the reporting frame around all of it, see PRISMA and systematic review methodology; for what the database underneath PubMed actually is, the dictionary entry on the MEDLINE database; and for the wider tooling landscape, CASRAI’s research tools hub.

Two adjacent jobs that are not this one: if you only need to establish that a source is peer-reviewed, searching for peer-reviewed articles is simpler; and if you are assembling your own publication record rather than running a review, see compiling one complete publication list.

What we could not verify

• Every count on this page is a snapshot taken on 26 August 2026 via the E-utilities esearch API. PubMed adds citations daily; the ratios should be stable in direction, but re-run any figure you intend to cite.
• On-screen Builder behaviour was not directly observed. We did not run the web interface. Statements about the autocomplete, the split Search / Add to History button, the More Actions menu, the red Warnings banner and what the Add button writes into the Query box are taken from NLM’s User Guide. In particular, we did not establish whether the Builder wraps a multi-word entry in quotation marks when it writes it to the Query box — that would change the result substantially, per the quoting measurements above, and it is worth checking in your own session rather than assuming either way.
• The invalid-tag divergence is unexplained. NLM documents a red warning for invalid tags in the web interface; the API silently dropped [abstract] and [zzz] and returned an empty fieldsnotfound list. We did not establish where the boundary between the two behaviours lies, so do not assume the API’s silence means your web search would also pass without a warning.
• The exact count of valid field tags is given here as "about fifty" from the User Guide’s list; NLM does not publish it as a number, and several entries (Owner, Comment Correction Type, PMCID and MID) are listed without a bracketed abbreviation.
• The 8-hour History expiry and the 100-search cap are documented by NLM but were not independently timed or exhausted by us.

Frequently asked questions

How do I combine two previous searches in PubMed?

On the Advanced Search page, use the More Actions ("…") icon on a History row and choose Add query to copy it into the Query box; AND, OR and NOT options appear as you add more. You can also type the search numbers directly: #1 AND #2. Measured 26 August 2026, #1 AND #2 over hypertension[mh] (340,893) and exercise[mh] (291,264) returned 5,913, with the combined row’s translation showing the full expanded expression rather than the numbers.

Why does my PubMed search return far more results than expected?

The most common cause is left-to-right Boolean processing with a missing pair of parentheses. Measured 26 August 2026: hypertension AND diet OR exercise returned 716,426 against 58,675 for hypertension AND (diet OR exercise) — a 12.2-fold inflation, of which 686,500 records are simply everything about exercise. The second most common cause is a field tag that only bound to the last word of a multi-word line.

What is Search Details in PubMed?

The expandable panel under each History row on the Advanced Search page, opened with the chevron icon. It shows Translations (how each of your terms was mapped, using PubMed’s own syntax) and Warnings (syntax errors, terms not found, invalid tags). It is the only place the query PubMed actually executed is visible, and it is what you copy into a reported search strategy.

Why is a term missing from the Translations list?

Because it was not translated. NLM documents that "query terms without translations will not be listed in this section; for example, exact phrases bypass Automatic Term Mapping." A term’s absence from Translations means it went in raw — which is exactly what quoting, wildcards and field tags all do.

Does putting quotation marks around a term in PubMed make my search more precise?

It makes it narrower, which is not the same thing. Quoting turns off Automatic Term Mapping, so you lose the MeSH half of the search. Measured 26 August 2026: heart attack returned 330,542 and "heart attack" returned 6,153 — 54 times fewer. Quote only when you genuinely want a literal string.

Why did my quoted phrase return zero results in PubMed?

Most likely the phrase is not in PubMed’s phrase index, which is a finite list, not a free-text match. NLM’s fix is a proximity search with distance zero. Measured 26 August 2026: "cognitive impairment in multiple sclerosis"[tiab] returned 0 with a "quoted phrase not found" warning, while "cognitive impairment in multiple sclerosis"[tiab:~0] returned 310.

Do I need to tag every term with a field tag, or just the last one?

Every one. NLM: "to search multiple terms in the same field, each term must be tagged individually." Measured 26 August 2026: covid-19 vaccine children[ti] returned 1,632 because only "children" was title-limited, against 331 for covid-19[ti] vaccine[ti] children[ti].

What happens if I use a field tag that does not exist?

In the web interface, NLM documents a red Warning for invalid tags. Through the E-utilities API on 26 August 2026, the tag was silently discarded: sepsis[abstract] and sepsis[zzz] both returned 249,546, identical to an untagged sepsis, against 150,862 for the valid sepsis[tiab]. An invalid tag broadens your search rather than breaking it, so check the translation.

How long does PubMed keep my search history?

NLM documents that History expires after 8 hours of inactivity and is capped at the last 100 searches, with the oldest dropped beyond that. It also requires cookies. Download the CSV before you stop working.

What is search number #0 in PubMed?

The citations currently in your Clipboard. NLM’s example is #0 AND english[la], which limits your clipboard to English-language records without altering the clipboard contents.

Should I use Show Index?

Yes, when you are unsure whether the string you want to match actually exists in a field. It lists the terms present in a chosen field with approximate counts, and NLM documents that the Builder "will automatically OR (and add parentheses) for multiple terms selected from the index" — the one place the interface handles nesting for you. It is unavailable for date fields and for some other fields.