InDesign Will Not Warn You About External Links

A document opens cleanly. No red flags in the Links panel, no warnings on export. It gets zipped, copied to a shared drive, or handed off as it stands. On the other machine, images are missing — not one or two, but a screenful.

Nothing broke in transit. The links were already pointing at places that were never going to travel with the file. They had been for weeks. The handoff was just the first moment anything depended on it.

Two Kinds of Bad Link, and InDesign Only Names One

InDesign is precise about link state. It will tell you a link is missing — the file is not where the document expects it. It will tell you a link is out of date — the file changed since it was placed. Both get a badge in the Links panel, and both are picked up by the default preflight profile.

There is a third situation it does not treat as a problem: the link resolves perfectly, and its source file lives somewhere that only exists on your machine. A different folder. A different drive. Someone's Desktop.

This is not a third link status, and InDesign is not wrong to omit it. The link genuinely is fine. Missing and out-of-date are observations about the file as it is right now. An external source is a different kind of fact — a dependency on a location that may or may not exist on the other side of a handoff. That is a property of the workflow, not of the link, which is why no badge covers it.

A linked file inside the Links folder is local, while a file elsewhere is external even when it is inside the same project folder.

What "External" Means Here

Worth pinning down, because everything below depends on it.

LinkSafe uses one deliberately strict rule: the canonical home for a linked file is the Links folder beside the INDD. Anything outside that folder is reported as external — including files elsewhere inside the same project folder, which would travel with the document perfectly well.

That is a workflow policy, not an InDesign category. If your shop keeps assets in Photos/ and Logos/ next to the document and always moves the whole tree, those links are fine in practice and LinkSafe will still list them. The strictness is the point: one canonical place means one test, with nothing to configure per project and nothing to get wrong.

The Panel Shows You a Name, Not a Relationship

It would be wrong to say the path is hidden. Open the Links panel menu, choose Panel Options, and you can switch on Folder 0, Folder 1, Folder 2 — the enclosing folder and its parents — as columns. Select a link and Link Info shows the full path.

So the information is there. What is not there is the comparison.

Folder 0 tells you a link sits in a folder called Images. It does not tell you which Images — the one beside this document, or the one on the shared drive, or the one in last year's job folder. Two links showing an identical folder name can point at completely different places. The panel gives you a label; what decides the outcome is a relationship between two paths, and there is no column for a relationship.

That leaves reading full paths row by row. It is fine at six links and stops scaling quickly, because a clean result is only provable by exhaustion: there is no shortcut to establishing that none of the remaining rows point somewhere else.

Meanwhile the state accumulates through ordinary work — duplicating last year's layout, reusing a logo from a shared folder, placing an image straight out of a client's download folder, opening a document built on a machine with different drive letters. Each one leaves a link pointing somewhere a handoff will not carry.

Package Fixes the Handoff, Not the Working Document

The obvious objection is that InDesign already covers this. File > Package copies linked graphics into a Links folder and, with Update Graphic Links in Package enabled, repoints the links at those copies. That is true, and for a handoff it is the right tool — done properly it prevents exactly the failure this post opens with.

The distinction is narrower than "Package is not enough," and it is worth stating exactly: Package makes a portable copy. It does not change the dependency structure of the document you keep working in. The links that get repointed belong to the copy inside the package folder. Your working file still points wherever it pointed before.

If production continues from the packaged copy, that is a complete answer and there is nothing left to do. If production continues from the original — the common case, since the original is what sits in the job folder and carries the edit history — then the underlying condition is untouched, and every future handoff depends on remembering to package correctly again.

Consolidating in place is the other operation. It changes the working document so that its eligible links resolve from the canonical Links folder beside the INDD. Packaging is still the right way to hand off afterward; by then the links are already consolidated.

This Is a Low Judgment Check

Once the canonical location is fixed by policy, deciding whether a given link satisfies it takes no judgment at all. At the scripting level it reduces to a deterministic path-containment test — after both paths are normalized, which is the part that is less trivial than it sounds: separators, trailing separators, and whether the volume is case-sensitive, which LinkSafe probes at run time rather than inferring from the operating system's name.

Objective detection, predictable action: that is the combination I have written about before as low judgment work, and it is the category that is safe to automate first. There is a second reason to hand it over, which only shows up later. Done by hand, the result exists in someone's head and there is nothing to point at afterward. Done by tool, the result is a file — and a file can be attached to a handoff, filed with the job, or read six months later when someone asks what happened.

Consolidation Is Four Operations, Not One

"Collect the links" sounds like one action — copy the files. It is four, and skipping any of them is where consolidation scripts usually go wrong.

Copy every eligible external file into the Links folder beside the document. Eligible carries weight: an embedded graphic has no external source to copy, because it is already stored inside the document; a missing file cannot be copied at all; a file already in the folder does not need to be. Three different reasons, and each should be recorded rather than silently skipped.
Relink the document to the copies. This is the step that changes the document, and the only one that does.
Verify each relink after making it. Not assume — read the link back and check both its status and its resolved path against the copy you intended. A relink that reports success and does not land is worse than no relink at all, because now the document looks consolidated.
Log the run. What moved, what did not, and why.

Name conflicts deserve their own note. Two different images called logo.eps from two different folders will collide in one flat folder. Blind overwrite is the unsafe answer: it leaves a file that still opens, still shows an image, and shows the wrong one. Several responses are defensible — preserve the source hierarchy, abort on collision, ask. LinkSafe renames the incoming copy (logo.eps, logo_2.eps) and never overwrites what is already there.

The Script

LinkSafe is an InDesign script that does the above. It has one mode that changes the document and three that only read it:

Collect & Relink — copy, relink, verify, log. The run is wrapped as a single InDesign undo transaction, so one Ctrl/Cmd+Z reverts every relink together.
External Links Report — a CSV of every link whose source sits outside the Links folder beside the document, with its path and a reason code.
Missing Links Report — a CSV of everything that is gone, keeping the recorded path so you know what to restore.
All Links Inventory — one row per link with its status: local, external, embedded, missing.

The three report modes do not touch the document. That separation is deliberate: on a file you did not build, you want to look before you change anything.

Worth knowing before leaning on it:

Undo covers the relinking, not the copying. The relinks revert in one step because the run is wrapped as one transaction. The copied files stay on disk — a filesystem operation is not something Undo can reach — and nothing already in the folder is overwritten. Delete the unused copies manually once you are satisfied with the document.
It does not collect fonts. Package does. Consolidating links is not a replacement for packaging; it removes one class of failure from it.
It does not reconstruct missing sources. If a recorded path no longer resolves, LinkSafe can list it but not rebuild it. Recovering the file from a backup, an earlier package, or the machine it came from is outside what a script can do.
It works on links, whatever they point at. Everything in the Links panel is in scope — graphics, placed INDD files, linked text — because the rule is about where a source file lives, not what kind of file it is. What it does not do is recurse: a placed INDD is copied and relinked as a file, but the links inside that document remain that document's own problem. Fonts and color settings are not links at all, and are separate concerns with separate failure modes.

Full walkthrough here: https://youtu.be/Ccm4zA4w6dw

LinkSafe is on aescripts, with a free trial: https://aescripts.com/linksafe/