What Is the _source Field in Elasticsearch?
A beginner-friendly, deep walkthrough of the field that quietly holds the original copy of every document you ever index — what it is, how it works internally, and when you'd ever want to turn it off.
Imagine a photocopier machine that, every time it makes a copy for you, also secretly keeps its own perfect duplicate of the original document locked in a drawer underneath — just in case anyone ever needs to reprint it exactly as it was. In Elasticsearch, that hidden drawer is called the _source field, and understanding what it stores, how it’s used, and why it sometimes gets turned off is essential to truly understanding how Elasticsearch documents work.
1What Exactly Is the _source Field?
Before anything else, let’s build a clear, simple definition.
The _source field is a special, built-in field that Elasticsearch automatically creates for every single document you index. It stores the original JSON you sent — exactly as it was, byte for byte — separately from all the clever internal search structures, like the inverted index, that Elasticsearch builds to make that document searchable.
In other words, when you index a document describing a book with a title, author, and price, Elasticsearch does two very different jobs at once: it breaks the text apart to build fast search structures (as covered in the earlier index tutorial), and it separately keeps a clean, untouched copy of your original JSON tucked away inside _source. When you later retrieve or search for that document, it’s this _source copy that gets handed back to you, looking exactly like what you originally sent.
Think of submitting a form at a government office. The clerk photocopies your form and files different pieces of information into different indexed folders — one for names, one for dates, one for addresses — so any piece can be found quickly later. But the clerk also staples your *original, complete form* into one special folder, untouched. If you ever come back and ask “what exactly did I submit?”, that original folder is what gets handed back to you — that folder is the _source field.
_source
The stored, original JSON body of a document, kept separately from the search structures built from it.
Stored Field
Any field value kept in its original form for retrieval, as opposed to only being indexed for search.
Source Filtering
A request option that lets you ask for only certain fields from _source, instead of the whole document.
Doc Values
A separate, column-oriented storage structure used for sorting and aggregations, distinct from _source.
It’s worth pausing on that distinction because it trips up many beginners: the inverted index (which makes search fast) and _source (which lets you get your original document back) are two completely separate things, stored differently, and serving two very different purposes.
2Why Does This Concept Exist?
Every technology exists to solve a real, painful problem. Here is the one _source solves.
To make full-text search fast, Elasticsearch has to break your document’s text apart, reorganize it into an inverted index, and often discard the original formatting in the process — stemming words, lowercasing them, removing punctuation. Once broken apart this way, the data is fantastic for searching, but essentially useless for reconstructing exactly what the original document looked like.
The Core Problem
Search structures like the inverted index are optimized for finding matches, not for perfectly reproducing the original document — yet almost every real application eventually needs to display, export, or reprocess the exact original data.
The _source field solves this by keeping a faithful, complete copy of the original document sitting right alongside all the search machinery, so applications never have to choose between “fast to search” and “possible to retrieve exactly as submitted.” You get both, because Elasticsearch stores both.
Without _source, showing search results to a user — like a product listing or a support ticket — would require Elasticsearch to somehow reverse-engineer the original document from scattered index fragments, which is often impossible once analysis and tokenization have taken place.
Beyond simple retrieval, _source also quietly enables several deeper Elasticsearch capabilities: reindexing (rebuilding an index with a new mapping), updates (changing part of a document), and highlighting (showing which part of the original text matched a search query) all depend on having the real, original document available somewhere — and that somewhere is _source.
3Architecture and Components
Where exactly does _source sit among Elasticsearch’s other storage structures?
Every document indexed into Elasticsearch actually feeds several different storage structures simultaneously, each built for a different purpose. Understanding how they relate makes it obvious why _source is neither redundant nor optional in most real setups.
Inverted Index
Maps analyzed words back to the documents containing them — built for fast full-text search.
_source
The compressed, original JSON body of the document — built for accurate retrieval and reprocessing.
Doc Values
A column-oriented store of field values — built for fast sorting and aggregations.
Stored Fields
Individual fields explicitly marked to be stored on their own, separate from the full _source blob.
graph TD
A[Incoming JSON Document] --> B[Analyzer / Tokenizer]
A --> C[_source storage]
B --> D[Inverted Index]
A --> E[Doc Values]
D --> F[Powers full-text search]
E --> G[Powers sorting and aggregations]
C --> H[Powers document retrieval, reindexing, updates]
Picture a chef preparing one big meal for three different purposes: some ingredients get finely chopped and mixed for a fast-cooking sauce (the inverted index), some get sorted into labeled jars by type for easy weighing later (doc values), and the entire original recipe card itself gets pinned to the wall exactly as written (_source), so anyone can double-check exactly what was meant to go into the dish.
By default, when you create an index without changing any settings, _source is enabled and captures the entire original document. It’s stored in a compressed form to save disk space, since JSON text tends to compress very well, especially across many similar documents.
4How It Works Internally
What actually happens to your JSON the moment you send it?
When a document arrives for indexing, Elasticsearch takes the raw JSON body exactly as received and stores it as a single, compressed blob inside the shard, tagged with that document’s unique ID. This happens independently of, and in parallel with, the analysis pipeline that builds the inverted index from the document’s text fields.
Receive Raw JSON
The document arrives exactly as sent by the client, before any analysis or transformation happens.
Store as _source
The untouched JSON is compressed and stored as the _source value for that document’s unique ID.
Analyze in Parallel
Separately, text fields are tokenized and written into the inverted index, unaffected by the _source copy.
Retrieve on Demand
When a document is fetched or matched by a search, its _source blob is decompressed and returned.
Because the inverted index and _source are built and stored independently, disabling one has no effect on the other’s ability to function for its own purpose. You could, in theory, disable _source entirely and searches would still work perfectly — you simply wouldn’t get the original document contents back in your results, only which documents matched.
Many beginners assume Elasticsearch “reconstructs” a document from the inverted index when you search for it. It does not. The document you see returned always comes directly from the stored _source, not from reassembling tokenized fragments.
An important, related capability is source filtering: instead of always retrieving the entire _source blob, a search or fetch request can specify exactly which fields to include or exclude. Elasticsearch still decompresses the full blob internally, but only returns the requested subset over the network, saving bandwidth for documents with many large, rarely-needed fields.
5Data Flow and Lifecycle
Following _source through the full life of a document, from write to eventual use.
sequenceDiagram
participant Client
participant Shard
participant SourceStore as _source Storage
participant InvertedIdx as Inverted Index
Client->>Shard: Index document (JSON)
Shard->>SourceStore: Compress and store original JSON
Shard->>InvertedIdx: Analyze text and update index
Client->>Shard: Search or Get request
Shard->>InvertedIdx: Find matching document IDs
Shard->>SourceStore: Fetch and decompress _source
SourceStore-->>Client: Return original document fields
Beyond simple retrieval, _source plays a quiet but critical role in several other operations that many users don’t realize depend on it directly.
Partial Update
Updating just one field of a document works by reading _source, merging in the change, then reindexing it.
Reindexing
Moving data into a new index with a different mapping relies entirely on reading each document’s _source.
Highlighting
Showing the exact matched text in context typically re-examines the original text stored in _source.
Snapshot & Restore
Backups capture the underlying stored data, including _source, so restoring recreates full documents.
This is why disabling _source is considered such a significant decision, discussed further in Chapter 7 — it doesn’t just remove a “nice to have” convenience field, it quietly removes the foundation that several important, everyday operations are built on top of.
6Common Uses and Real-World Examples
How _source actually shows up in everyday Elasticsearch usage.
Displaying Search Results
An e-commerce search bar returning product listings relies entirely on _source to show the title, image URL, price, and description exactly as originally cataloged, without any reconstruction guesswork.
Rebuilding Indices After a Mapping Change
When a team realizes a field should have been mapped differently, they use the reindex operation, which reads every document’s _source and writes it into a freshly mapped index — something impossible without _source intact.
Debugging and Auditing
Engineers investigating a data quality issue often fetch a document directly by ID specifically to inspect its raw _source, confirming exactly what was originally submitted before any processing occurred.
Bandwidth-Conscious Applications
A mobile app displaying only a product’s name and price in a list view can use source filtering to request just those two fields, avoiding the cost of transferring a large, full product description over a slow connection.
| Scenario | Relies on _source? | Notes |
|---|---|---|
| Returning search results | Yes | Default behavior for most search requests |
| Counting matching documents | No | Only needs the inverted index, not the original data |
| Partial document update | Yes | Reads and rewrites the existing _source |
| Aggregation on a numeric field | No | Uses doc values instead of _source |
7Advantages, Disadvantages and Trade-offs
Keeping a full original copy of every document isn’t free — here’s the honest trade-off.
Advantages
- Guarantees the exact original document can always be retrieved, unchanged.
- Enables reindexing into new mappings without needing the original data source again.
- Makes partial updates possible by providing something to merge changes into.
- Supports accurate highlighting of matched search terms in their original context.
- Simplifies debugging, since the raw submitted data is always just one lookup away.
Disadvantages / Trade-offs
- Increases disk usage, since the full original document is stored in addition to search structures.
- Retrieving very large documents can add unnecessary network overhead if only a few fields are needed.
- Disabling it to save space permanently removes the ability to reindex or partially update easily.
- Sensitive data included in _source is also duplicated wherever the document is stored or backed up.
For the overwhelming majority of use cases, the benefits of keeping _source enabled far outweigh the modest storage cost, which is why it remains on by default. Disabling it is a specialized, advanced decision usually reserved for very large-scale, storage-sensitive systems where the original data is safely stored somewhere else entirely.
8Security Considerations
Because _source holds the complete original document, it deserves careful handling.
Since _source contains the entire original document, any sensitive information included in that document — personal details, internal notes, financial figures — is fully present and retrievable from it, not just from whatever fields happen to be searchable. Protecting an index’s data really means protecting its _source.
Field-Level Security
Restrict which fields specific users or roles are allowed to see within returned _source content.
Avoid Indexing Secrets
Never send raw passwords, tokens, or other secrets into a document, since _source will store them as-is.
Encrypt at Rest
Since _source is stored on disk, disk-level encryption protects it the same way it protects any other data.
Secure Backups
Remember that any snapshot of an index also captures every document’s full _source content.
Assuming that hiding a field from search results (via source filtering) makes it “secure.” Source filtering happens on the response side; someone with a broader query permission or direct API access can still request the full _source unless proper field-level security is configured.
9Monitoring, Logging and Metrics
What to watch to make sure _source usage stays healthy at scale.
Because _source contributes directly to an index’s storage footprint and to the bandwidth consumed by search responses, a few specific signals are worth tracking as data volume grows.
Index Storage Breakdown
Some monitoring tools can show how much of an index’s total size is attributable to stored _source data.
Average Response Size
Tracking the size of search responses helps identify whether source filtering could meaningfully help.
Large Field Usage
Identifying fields rarely used in results but consistently large helps target source filtering effectively.
Reindex Duration
Since reindexing reads every document’s _source, its duration is a useful proxy for _source read throughput.
None of these require exotic tooling — most are visible through an index’s basic storage statistics and standard search response monitoring, but they’re easy to overlook until an index unexpectedly grows far larger than its raw searchable content would suggest.
10Design Patterns and Anti-patterns
Sensible approaches to _source management, and the mistakes worth avoiding.
Source Filtering by Default for Large Documents
A proven pattern for indices with large documents — such as full article bodies — is to always apply source filtering on search requests, returning only the fields actually needed for a results list, and fetching the full document separately only when a user opens it.
Keeping _source Enabled by Default
Unless there is a very specific, measured reason not to, leaving _source enabled preserves the ability to reindex, update, and debug freely — flexibility that is expensive to regain later if lost.
Problem
Disabling _source purely to save disk space, without first confirming that the original data is safely retained somewhere else.
Why It’s Harmful
Once _source is disabled and documents have been indexed, reindexing into a corrected mapping or performing partial updates becomes impossible for that data; the only recovery path is re-indexing from the original external source, if one still exists.
Correct Approach
Only disable _source when the original data is durably stored elsewhere (such as a primary database or object storage), and the specific storage savings have been measured and justified.
Problem
Returning the entire _source on every single search request by default, even when the application only ever displays two or three fields.
Why It’s Harmful
Unnecessarily large response payloads waste network bandwidth and slow down applications, especially at high query volume or on constrained connections like mobile networks.
Correct Approach
Apply source filtering to request only the fields the application genuinely needs for the current view, fetching the full document separately only when truly required.
11Best Practices and Common Mistakes
Practical, field-tested guidance for working with _source day to day.
Leave _source enabled by default
Only disable it after a deliberate, measured decision, never as an early, casual optimization.
Use source filtering for large documents
Request only needed fields for list views, and fetch the full document only when genuinely necessary.
Never index raw secrets
Keep sensitive values like passwords or tokens out of documents entirely, since _source stores them as-is.
Confirm reindex dependency
Before disabling _source on any index, confirm no future reindexing or update workflow depends on it.
When designing a new index, ask early: “will I ever need to reindex or partially update this data?” If the honest answer is yes — which it usually is — that alone is often reason enough to keep _source enabled.
A frequent beginner mistake is confusing “not shown in the UI” with “not stored.” Just because an application chooses not to display a field doesn’t mean that field isn’t sitting inside _source, fully retrievable by anyone with the right query permissions — a distinction that matters greatly for privacy and compliance.
Another common mistake is disabling _source on an index storing data that has no other durable copy anywhere else — for example, data generated only within Elasticsearch itself through complex transforms. In that situation, disabling _source can mean the original, pre-transform data is permanently unrecoverable.
12Frequently Asked Questions
Quick, direct answers to the questions beginners ask most often about _source.
No. The inverted index is built from analyzed, tokenized text used purely for searching; _source is a separate, complete copy of the original, unmodified document.
Not exactly — _source is typically an all-or-nothing setting for a document type, though source filtering lets you choose which fields are returned on any given request without disabling storage itself.
Search matching itself relies on the inverted index, not _source, so disabling it mainly saves disk space and can reduce response payload size, rather than speeding up the actual matching process.
Partial document updates generally require reading the existing _source to merge changes into it, so disabling _source typically also disables the ability to perform such updates.
Yes. Elasticsearch compresses stored _source data to reduce its disk footprint, decompressing it only when a document is actually retrieved.
Source filtering controls what a request asks to see, not what a user is permitted to see — true access restriction requires proper field-level security configured at the permissions layer.
13Summary and Key Takeaways
The _source field is the quiet foundation underneath nearly every practical Elasticsearch workflow — the faithful, original copy of a document that makes retrieval, updates, reindexing, and debugging possible, all while the inverted index and doc values handle the separate job of making that same data searchable and sortable at speed. Understanding _source deeply means understanding why Elasticsearch can be both a blazing-fast search engine and a reliable place to get your original data back, without compromise on either front.
Key Takeaways
- _source stores the original document — a faithful, compressed copy of the exact JSON you indexed, kept separately from search structures.
- It is distinct from the inverted index and doc values — each structure is built independently for its own specific purpose.
- Retrieval, updates, and reindexing all depend on it — disabling _source removes the foundation these operations rely on.
- Source filtering lets you request only what you need — reducing response size without disabling storage itself.
- Sensitive data inside _source is fully retrievable — protecting it requires field-level security, not just hiding it from a UI.
- Disabling _source is a specialized, deliberate decision — appropriate only when the original data is safely stored elsewhere.
- Leaving it enabled by default preserves flexibility — a small storage cost in exchange for significant operational freedom.