Import is the moment a lot of reference libraries go wrong: a tool that copies every image into its own managed folder doubles your disk usage, breaks whatever folder structure you already trusted, and ties your pictures to whichever app did the importing. The five tools below are built the other way — they read a folder where it sits — and two more get named honestly for how close they come without quite qualifying. Checked 5 September 2026.
The reason this distinction is worth a whole page rather than a footnote in a review: it is very easy to not notice a copy happened until the disk fills up or the folder you thought was authoritative turns out to be a stale duplicate. Most vendors do not lie about which model they use — they simply don't say, and "import" quietly means "copy" in more catalogue apps than it should. Reading the actual documentation, the way every entry below does, is the only reliable way to know before you have already pointed the app at a hundred thousand files.
Adobe Bridge — browses folders live, writes metadata into the file
Adobe's own page offers Bridge as a free download. It opens a folder and shows what's in it directly, rather than importing anything into a database first, and ratings and keywords get written into the files themselves as XMP — metadata that travels with the picture if you move it, rather than living only in Bridge's private index. It also reads a genuinely wide range of formats — raw camera files and PDFs among them — that most reference-focused tools on this page do not touch at all, which is a real reason to keep it around even alongside something else. Full comparison.
Finder tags — not even a separate index
The strictest version of "doesn't copy" available: Apple's Mac user guide describes tags as an attribute you add to a file directly, from the File menu or by Control-clicking. There is no second location for the data to live — it's written onto the file's own metadata, on the same disk, in the same folder. The cost of that simplicity is search: Finder tags scale to a favourites list of seven and a collection small enough to browse by eye, and there is nothing resembling a query line once a folder grows past a few thousand images. Full comparison.
XnView MP — a browser, not a library
Free for private or educational use, with commercial licences starting around €29 per seat. It runs on Windows, macOS 11.3+ and Linux and works the way a file manager works: you point it at a folder and it shows you what's there, rather than ingesting anything into a database of its own. Fast for a quick look at a folder of unsorted references, thin on the tagging and saved-search side compared to a purpose-built catalogue, and cross-platform enough to be worth knowing about if part of your work happens on a Windows machine too.
ImageRanger — indexes drives, including ones you can't index live
Runs on Windows and macOS, and its own site describes indexing files on a NAS or a disconnected storage drive, which only makes sense if the app is reading metadata from where the files are rather than pulling copies into itself. Its pricing page lists a one-time payment for the Home edition and a two-machine Pro tier, both including a year of updates. Reaching into drives you cannot mount live is the specific case where a "does not copy" claim actually matters most: you cannot copy files off a disconnected drive without connecting it, so an index built purely from that drive's own metadata is the only way the feature works at all.
Peakto — built specifically around this one claim
A Mac cataloguing tool whose whole pitch, per its App Store listing, is to "manage your pictures without creating copies," unifying images already sitting across other apps' catalogs, sessions and folders into one searchable view rather than pulling them into a library of its own. Version 2.7.10 as of this writing, priced as a subscription — $14.99 a month or $144.99 a year on the App Store, after a one-week trial. Pick it if you already have images scattered across several other cataloguing apps and want one search over all of them without a second migration. The trade for that convenience is the subscription itself — there is no one-time tier on the App Store listing, so the "no copies" promise comes bundled with an ongoing bill rather than a one-off purchase the way most of the rest of this page does.
Two boards that almost qualify, and where the line actually is
PureRef and BeeRef both deserve real credit here and a caveat in the same
breath. Neither ever moves, renames or deletes your original file — the
picture stays exactly where you found it. But both save their board as a
single file that embeds the image data itself: PureRef's .pur scene and
BeeRef's .bee — documented by BeeRef as a SQLite database with the images
stored inside it — both keep a private copy of the
pixels the moment you drop something onto the canvas. That is a defensible
trade for a board you want to be self-contained and portable as one file, and
it is a real copy of the data in a way Bridge, XnView, ImageRanger and Peakto
are not. Neither app is being dishonest about this — it is simply a different
design goal, a portable single-file board rather than a live index over a
folder — but "board" and "library" are different enough jobs that the
distinction is worth spelling out rather than letting the word "board" imply
"library" by accident. PureRef comparison,
BeeRef comparison.
Why so many catalogue apps copy in the first place
It is not usually laziness on the vendor's part. Copying into a private library folder solves real problems: the app can guarantee the file will not move out from under it, can control the exact folder structure its database expects, and can bundle everything into one place that is trivial to back up or move as a unit. The cost lands entirely on the user — doubled disk usage, a second copy that can drift out of sync with the original, and a library that is only portable if the app itself provides an export path. Reading a folder in place instead is strictly harder for the app to build well, which is exactly why it is worth crediting the tools on this page that took the harder path rather than assuming every catalogue app made the same choice.
Coii Ref — indexes in place, writes nothing into your pictures
Coii Ref reads the folders of images and video already on a Mac and indexes them where they sit — never copied, moved or renamed. The database, thumbnails and proxies it needs live inside the workspace folder you point it at, beside your files rather than mixed into them, so deleting Coii Ref entirely leaves your pictures exactly as they were. $19 once, three Macs, thirty days with every feature. Do not pick it if you want metadata written into the files themselves the way Bridge's XMP does — Coii Ref's tags and ratings live in its own workspace file, not inside your images. Full comparison.
All seven, on where the copy actually happens
| Copies the original file | Copies image data anywhere | Metadata location | |
|---|---|---|---|
| Adobe Bridge | No | No | Written into the file (XMP) |
| Finder tags | No | No | Written into the file |
| XnView MP | No | No | Its own sidecar/cache |
| ImageRanger | No | No | Its own database |
| Peakto | No | No | Its own database |
| PureRef | No | Yes — embedded in .pur |
Inside the board file |
| BeeRef | No | Yes — embedded in .bee |
Inside the board file |
| Coii Ref | No | No | Its own workspace folder |
How to test a "does not copy" claim yourself in two minutes
Do not take a vendor's marketing page at face value, including this one's for
Coii Ref. Point any app you are evaluating at a small test folder — ten images
is plenty — and after it has finished importing or indexing, check the app's
own data folder (usually named in its documentation, or findable in
~/Library/Application Support on a Mac) for a second copy of those same
files. If the pixels exist twice on disk, it copies, regardless of what the
word "import" implied. If your ten test files exist exactly once, wherever you
put them, it indexes in place. This test takes less time than reading a
support article and settles the question definitively, for any app, including
ones not on this page.
What a copy actually costs beyond disk space
Disk space is the visible cost and rarely the worst one. The quieter cost is provenance: once a picture exists in two places, "which one is current" stops being obvious, and an edit made to the original — a crop, a colour correction, a simple rename during a folder cleanup — silently does not reach the app's own copy. Months later, a search inside the app can surface the stale version with no indication that a newer one exists somewhere else. None of the apps on the strict half of this list can produce that failure mode, because there is only ever one file to be right or wrong about.
Video makes all of this worse by an order of magnitude. A four-minute 4K clip easily runs past a gigabyte, and a library of a few hundred such clips turns a "doubled disk usage" problem from an inconvenience into a real decision about which external drive to buy. Anyone whose reference collection leans toward video specifically has more reason than most to care which model an app uses, because the arithmetic punishes a wrong choice faster.
Why this is worth checking before you commit
A copy is a second thing to keep in sync. The moment an app holds its own version of a picture, editing or replacing the original elsewhere leaves the app's copy stale, silently, until you notice a caption on the wrong version of a file.
Disk usage compounds with video. A duplicated 4K clip costs real space; a library of them costs a lot of it. Every app on the strict half of this list avoids that cost entirely because there is nothing to duplicate.
"In place" is a promise worth verifying, not assuming. Several vendors state it plainly — Adobe, Peakto and ImageRanger all do — and the ones that do not say it explicitly are usually importing, the way Eagle's own documentation confirms it does. Check the vendor's own page before trusting a review that assumed otherwise — the two-minute test above works just as well on a vendor's claim as it does on an assumption you made yourself.
A copied library is also a copied liability. If a catalogue app's own storage becomes corrupted — a crashed write, a bad external drive, a failed update — an app that copied your images has put a second, equally fragile version of them at risk alongside the originals. An app that only ever reads files in place cannot corrupt what it never wrote a copy of; the worst case is a broken index that gets rebuilt from the files that were never touched.
If keeping your folders untouched is the whole reason you're reading this, download Coii Ref and point the thirty-day trial at a folder you already trust — nothing about the process changes what's inside it. Run the two-minute test above on it first if you want to verify the claim rather than take this page's word for it, the same way you should for anything else on this list — including whatever you are already using today.