Data merge in InDesign is a built-in feature that populates a layout with content from a spreadsheet. You place field placeholders on the page, connect a CSV or delimited TXT data source, and InDesign generates one set of content per record. It handles text and images, it is included with every InDesign license, and it is the standard method for producing catalogs, price lists, and directories without manual copy and paste.
The panel lives under Window > Utilities > Data Merge. Everything below is written for a product catalog, which is the hardest job data merge is commonly asked to do.
Most failed merges fail here rather than inside InDesign.
File format. InDesign accepts comma-delimited CSV, tab-delimited TXT, and semicolon-delimited files. Tab-delimited is the safer choice for catalogs, because product descriptions almost always contain commas.
Encoding. Current versions of InDesign support UTF-8, with or without BOM, which covers accented characters, multilingual content, and symbols. If you are on an older release, or if you are working with a complex script such as Thai, Hindi, or Myanmar, UTF-16 remains the more reliable option and is still the standard advice in the Adobe community. Either way, set the encoding deliberately in your text editor rather than accepting whatever Excel exports by default. Garbled characters in a merged document almost always trace back to this step.
Column headers. One header row, no blank columns, no merged cells, no leading or trailing spaces, and no duplicate field names. Header names become your field names in InDesign, so Product_Name is easier to live with than Product Name (final v2).
One row per product. Data merge has no concept of grouping or nesting. A product with three size variants is three rows or three columns, depending on the layout. It cannot expand a single record into a variable number of lines.
Close the file before merging. A source file open in Excel is locked, and the merge will fail or return empty records.
A minimal catalog source looks like this:
If your data changes after you have connected it, use Update Data Source from the panel menu rather than removing and re-selecting the file. Re-importing a file with the same name can leave InDesign holding the previous import settings in memory.
This is the section that stops most people, so it gets the most detail.
Mark the column with @. An image column header must begin with an at sign: @Photo, @Product_Image. Without it, InDesign treats the cell as text and prints the file path on your page instead of placing a picture.
Excel will resist. A cell beginning with @ is read as the start of a formula. Type a straight apostrophe before it, so '@Photo, and Excel stores it correctly. Confirm by opening the saved file in a plain text editor before importing.
Paths. The cell value is a path to the image file, absolute or relative to the location of the data source file.
Relative paths are the better default on a catalog project, because absolute paths break the moment the folder moves to another machine.
Verify a path rather than typing it from memory. Place one image manually in InDesign, select it in the Links panel, then choose Copy Info > Copy Full Path from the panel menu. That gives you the exact string InDesign expects, which matters most when images sit on a server or network share.
Set fitting before merging. In the Options tab of the Create Merged Document dialog:
Keep Link Images enabled. Also in the Options tab. Unchecked, InDesign embeds every image in the merged file, and a catalog of any size becomes unopenable.
Turn on Alert When Images Are Missing. InDesign will flag records where the path did not resolve rather than silently producing empty frames.
For a product grid you need more than one record on the page.
In Create Merged Document > Records per Document Page, select Multiple Records, then open the Multiple Record Layout tab to set margins, whether records flow by row or by column, and the spacing between them. Preview Multiple Record Layout shows the arrangement before you commit.
Three constraints that decide your template design:
Your template must be a single page. This is the actual cause behind almost every "Multiple Records is greyed out" question. A template with two or more pages restricts data merge to single-record mode. Delete the extra pages; multiple pages in the master are fine.
Everything on the document page repeats. Data merge duplicates the entire page content for each record, not just the placeholders. Section headers, rules, background graphics, and page furniture belong on the master page, or they will appear once per product. A large background image on the document page can also occupy enough room that InDesign decides only one record fits and falls back to single-record mode.
Spacing is uniform. Every record gets identical treatment. There is no variable gutter and no way to give a hero product a double-width cell.
Two checkboxes in the Options tab do work you would otherwise do by eye:
Turn both on every time. They do not fix the problems, but they tell you where they are.
InDesign data merge is a genuinely good tool, and it is free with a license you already own. It is also a one-way, static operation, and that is where catalog projects run into trouble.
Records cannot flow as a continuous story. This is the most catalog-specific limitation and the one that surprises people. Each merged record is a standalone duplicate of the placeholder elements rather than content flowing through a single threaded text frame. Add a product and you re-merge. Delete a product and you are left with a gap where it was. Any change to the number of records means generating the document again from scratch. Tools built specifically for catalogs, Catalogy among them, treat the product list as the thing that flows and let pagination fall out of it, which is why adding a SKU there is an edit rather than a rebuild.
The layout cannot react to the data. There is no conditional logic. You cannot say "if this product carries a certification badge, show the badge block, otherwise close the gap." Products carrying different amounts of information have to be forced into one identical shape, or split into separate merges with separate templates.
Text length is not handled. Overset is reported but never resolved. There is no auto-fit and no reflow.
Styling inside a field is not possible. You cannot bold one word inside a merged description. The whole field takes one style.
Facing-page layouts are not supported. For a catalog designed as spreads, that is a structural problem rather than an inconvenience.
Manual edits do not survive. Change a price and you re-merge, which discards every correction made since the last merge: every nudged frame, every fixed overset, every manual exception. Teams updating quarterly either redo all fixes each cycle, or stop merging and start editing the InDesign file by hand, which puts them back where they began. This is usually the point at which a team starts looking at catalog automation, and it is the specific problem platforms like Catalogy are built around: corrections live in the template and the rules, so regenerating from updated data does not throw them away.
Versions multiply. Three regions, four languages, and two price tiers is not one merge. It is separate source files, separate merges, separate output, and separate proofing, all drifting apart over time.
Volume degrades, and the workarounds are unreliable. There is no published record limit, but memory use and PDF export time climb steeply, and large merges are a long-standing source of stalls and crashes. The obvious workaround has a known flaw: Record Limit per Document splits output correctly when creating merged InDesign documents, but has not worked when exporting directly to PDF, producing one combined file instead of batches. Teams end up splitting source files by hand or running third-party scripts.
If you are producing a catalog of a few dozen to a couple of hundred products, once or twice a year, and the person building it already knows InDesign, data merge is the correct answer. It costs nothing extra, it produces print-ready output, and no software purchase will pay for itself against that workload. Set it up properly, document the source file format so the next person can reproduce it, and move on.
The calculation changes on three signals, and in practice they arrive together:
At that point the constraint is not design skill. It is that a static, one-way merge is being asked to behave like a system of record, and the reconciliation between the spreadsheet, the InDesign file, and the last approved PDF quietly becomes someone's full-time job.
Worth saying before that reads as a binary choice: outgrowing data merge does not mean abandoning InDesign. Catalogy integrates with InDesign, so layout work continues where your designers already are, while product data, versioning, and regeneration are handled outside the file. What you give up is the manual reconciliation, not the design tool.
The category that solves this is catalog automation, sometimes called database publishing. Rather than exporting a snapshot to CSV and merging it into a layout, the layout stays connected to the product data. Content flows in on demand, the layout responds to variable content length, rules govern what appears for which product, and producing another version is an action rather than a project.
Catalogy works this way: catalogs are generated from live product data rather than merged from a static export, so a price change updates every output that uses it, across print and digital, without rebuilding the file. If your team is running data merge on a catalog that changes more often than it was designed to, that is the gap worth looking at. Book a demo and bring your current source file.
InDesign data merge does one job well: it fills a fixed layout with data you hand it, once. For a catalog that is designed, approved, printed, and then left alone, that is the whole requirement, and the feature is already on your machine. Set the source file up carefully, keep the template to a single page, use POSIX paths on macOS, and turn on the overset and missing-image reports. Most merge failures are prevented at that stage rather than fixed later.
The tool runs out of room when the catalog stops being a document and starts being a process: data that changes weekly, hundreds of SKUs, several versions in parallel. Nothing in the merge is built to carry state between runs, so every cycle starts from zero and every manual fix has to be made again. If that describes your last three catalog cycles, the problem is no longer the layout, and no amount of InDesign skill will resolve it.
If you want to see what the same workflow looks like when the data stays connected to the layout, book a demo and bring the source file you are using today.
Can InDesign data merge pull images from a URL?
Not natively. Images must be available locally or on a mounted drive, and an http or https address in the image column will not resolve. Workarounds are a script that downloads the files and rewrites the paths, or a third-party plugin. Bridge to Catalogy: assets referenced through the product record, used where they already sit.
Can data merge apply a different layout to different products?
No conditional logic. Every record gets identical treatment. Bridge: rule-based layout is the actual dividing line between data merge and catalog automation.
How do you update a catalog after the data merge is finished?
You re-run the merge and lose every manual correction. No partial update, no refreshing a single record. Bridge: layout stays connected to the data, so an update regenerates output without discarding the work around it.
How do you stop a catalog being edited off-brand after it is produced?
InDesign has no control once the file is shared. Locked templates fix fonts, colours, logos and required messaging while leaving designated fields editable. Bridge: template-level control, so regional and sales teams produce versions without breaking the brand.
How many records can InDesign data merge handle?
Already in the draft. No documented limit, but export time and crashes climb, and Record Limit per Document is unreliable on PDF export.
.png)