Link Specific Text from One Document to Another?

I was wondering if there was a way to reference a particular section of text from one document in another and have a two way link between them.

As an example, I’m writing a novel and would love to see all of my notes/revision needs on a macro level in one revisions document. So I’d love to be able to go into my revisions/notes document, and have a link to a specific section of text in chapter 1 that I can click on and will take me to that section of the document. It seems like I can do the reverse of that - highlight text in chapter 1 that will take my to my revision document, but it doesn’t go both ways.

If I’m overcomplicating and there’s an easier way to do this that would be great! But I’d love to be able to look at one document that has a list of things I want to change that is linked to the text I’d like to change.


1 Like

This is a very broad topic in Scrivener, as you might imagine, and in my opinion it is one of the areas that it really excels in over other tools on the market. This is an area that is best described as a gestalt of practices and multiple smaller features. That means much of how you do things will can be interchangeably swapped out to taste. The core approach itself is quite simple—basic almost—but it creates a foundation upon which we can build predictable complexity, if necessary. Most of what you read below are techniques I use in the same project, it depends on what unique advantage I want from the approach, and since they are all closely related in the basic features they work from, different techniques can mingle in similar workflows.

This is also something that gets asked about quite a lot, and I’ve always had it on my list to pull together smaller notes and ideas from past threads and discussions on the matter, into one place. This will be quite long, I hope you do not mind. :slight_smile:

Keeping Things Small

When this comes up, the first thing I like to point out, which can often passively mitigate the need for anything like direct linking in the first place, is that the software in general works better the smaller and more individually topical each chunk of text is. The inclination, especially coming from word processors, is to pack long texts, like whole chapters, into each “file” in the binder. Scrivener on the other hand works just as well if one “file” is an abstract concept that is technically fifteen or twenty smaller binder items. Scrivenings mode makes it possible to work with them as one, and of course the compiler does that naturally by its design.

My rule of thumb: when I feel a section needs more metadata or easier ways to get around within it, my first reaction is to break it up into smaller subdocuments.

In short, if the chunks of text in your binder or short enough that scrolling is a rare thing you have to do in the first place, then odds are very high that any general link to the item itself is going to suffice for specificity.

Marking and Navigating to Any Text Precisely

Working with small chunks of text is all well and good as an ethos for using Scrivener, but there are times where it is not appropriate to split up a chunk of text (especially not for purely mechanical reasons like linking), and of course some people just don’t like working that way. While Scrivener is designed to get better the smaller chunks are (and hopefully the above illustrates to just what degree I mean that), it certainly is quite good even without doing so.

The technique that I use to directly link to any spot in the document is best described as a mix of two ingredients:

  1. An approach that has worked for decades: simply put a marker in the text where you want to link to, and then reference than marker from any place you want to link from. This all by itself is so basic you can do it with nothing more than a plain-text editor in DOS—it’s a technique that can survive migration to and from nearly any software, and will remain robust for decades to come. It is also by nature a two-way link, since the marker is the same in both places. This is of course very similar to what we were doing before, more casually, with note titles and selected hyperlinked text.
  2. That all by itself requires some technology to make it convenient, however (never mind some convention for stripping them out when it comes time to publish). With Scrivener, along with some stock macOS tools, we can make this process extremely efficient, and only a couple of small steps more involved than clicking on a link.

The attached project is a simple demonstration of how this technique can be used.

  1. In Document A, you’ll find two examples. The first is a purely internal link for my own benefit. It is placed within an inline annotation so it won’t compile, and in this case the link is just the marker itself. The second example shows how a “public link”, one that your reader might see as a cross-reference, is followed by an annotated marker. (Whether links become public is a choice you make when compiling.)
  2. Both can be used in fundamentally the same fashion. Place the cursor anywhere inside the inline annotation, and use the Edit/Select/Select Annotation menu command. Since I work with inline notes a lot, I’ve added a custom shortcut to that command. So I just hit Ctrl-Shift-A.
  3. The next step is to press Cmd-E, which corresponds to the Edit/Find/Use Selection for Find command. This, by the way, is a common Mac shortcut you’ll find almost everywhere and it even works between native Mac programs. What it does is basically “type” this text into the Cmd-F find tool, but without bringing that window up. It’s purely in the background.
  4. Now we click the link to load the document with the marker in it.
  5. Hit Cmd-G (or Edit/Find/Find Next). This is like clicking the “Find Next” button in the window, but again we don’t need the window for any of this. We jump straight to the right spot in the longer document.

Again, this is just one approach. We may just as well use Quick Search for this, replacing the click + ⌘G step, and given Quick Search’s previously explored navigation + auto-scroll behaviour when selecting text matches, it is very efficient. You will note at that point you don’t even need a software link, but it’s probably handy to have one anyway (particularly for that handy back-link bookmark feature).

Creating Direct Links

In this example project the unique marker is being generated by simply inserting the current date and time. This is made convenient in Scrivener, which has a command for doing so. Try this:

  1. From either Document A or B, put your cursor somewhere and press ⇧⌘A to start an inline annotation.
  2. Use ⇧⌘⌥D or Insert/Current Date & Time. (You may note I type in spaces before and after that command as well, as I think that looks nicer and doesn’t confuse spell check.)
  3. As above, use the command to select the inline annotation and press ⌘C to copy it. Now you’ve got the whole thing (marker + notation formatting) on the clipboard, for pasting in the precise location you want to link to.
  4. The precise method you use to link to the document is up to preference, as there are many ways of doing so, but a good trick to be aware of here is that if you drag an item onto a selection of text, that text will be linked to the item. Again the Swiss Army knife Quick Search tool is superb for this task, as you can locate the target item swiftly, drag and drop it out of the result list onto the text to make a link.

Alternatives & Ideas

The date stamp is convenient, but it may not always be informative enough by itself. Often when I link to something, I prefer to jot down why I am doing so, so that in a year or two down the way I don’t find myself blindly following links in the off-chance there is some important reason for having done so in the past. Here are some ideas for making these markers richer:

  • Sometimes I like to know whether what I’m looking at is a “target”, and I’ll use a way of marking the marker to indicate that. For myself I have a system I’ve been using since 2004 or so, where outbound markers look like “<|re20186737|>”, and inbound markers look like, “>|20186737|<”. This is an extremely compact format that indicates directionality, link type with the prefix (“re” in this case, indicates the link is going to bring up a piece of communication that this text was composed as a response to), followed by a condensed year+day+time format.

    This approach also gives me information to search for around the specific marker. Running a project search for “<|re” for example, has obvious potential.

    For most people, that’s probably too dense and cluttered and complicates the selection process too much, but it might give you some ideas for how you could do this. I prefer plain-text solutions, but you might be more comfortable indicating outbound links with red annotations and inbound links as blue, to provide Scrivener-specific approach.

    Or maybe you like the idea of text, but want something that looks nicer. Just to pull from one category in Unicode, arrows provide an veritable wealth of semantic information, making “⇇20186817”, “⥵20186817”, “:arrow_up:︎20186817” and “:arrow_down:︎20186817” all individually meaningful and capable of search tricks. Had I developed my system in 2020 instead of 2004, I’d have probably gone with Unicode symbols over ASCII! :wink:

  • Markers like this can do something that software hyperlinks cannot do, they can create a cluster result of relative points of interest in a large pool of data, where any one of those instances is an entry point into the rest of the cluster.

    Returning to the sample project, the second example shows how a marker needn’t be linked itself—maybe this particular marker is placed into a dozen different binder items, and we are less interested in getting to any one of those, but would rather see all of the cluster. To use a marker in this fashion, one would copy it using the previously described technique, with ⌘C substituted for ⌘E, and then paste the marker into the Project Search tool. You’ll get a precise list of matching items in the left sidebar, and can flip through marker hits in the main editor with ⌘G (the software will do the ⌘E part for you whenever you use project search). Commonly referenced markers are excellent candidates for saved search Collections.

  • Combined with a systematic approach to marker creation, cluster results like these can be predictable. Date and time is handy, but sometimes a cluster is important enough to be recalled at any time without having to find an instance by hand to know what marker to search for. This is when I use generalised markers, like “RSCH//” to indicate bits of text requiring further research, and that may be all I put into the inline annotation—I might also explain myself after the slashes, it’s flexible.

    And of course, having a convention like “//” all by itself gives us the opportunity to very easily jump from one edit note to the next in a broad way, via the Edit/Find/Find by Formatting tool, set to inline annotation search mode (and again, not colour can be used semantically by that tool, if you prefer that to plain-text approaches).

  • So to combine these different threads together, in some cases it might be very beneficial to have an annotation like this: “TODO// 2020-07-04 at 18:51”. Now you’ve got two things going on here. You can hop directly to this chunk of text from anywhere else since it has a unique marker, but you can also locate this generally, by running a project search (likely as a saved collection, for something like an embedded To Do list!) for “TODO//”.

Lastly, a few alternative tools that could be swapped around within the framework of this approach:

  • I’ve used inline annotations in all of my examples. I like to keep stuff like this in my face, so I can’t ignore it, and as easy to interface with as the source text itself. Some do find it obtrusive however, or may struggle with clutter if their note-taking/tagging is dense. The Comments tool can substitute for every application above, and in some ways offers a superior feature set, as it builds a navigable digest of your note markers in the sidebar. The downside is that you have to use GUI techniques to access them, rather than simple text editing techniques.
  • Styles are a newer tool to Scrivener that have interesting potential in this area of use. They follow the inline annotation principle, but styles used in this fashion can be set to delete their text when compiling—and because they are styles, you can codify meaning right into the marking itself. You can click on a linked date stamp and see “Research Note” printed in the Format Bar. Styles can also be searched for using the formatting finder, and the Styles panel also has a convenient up/down arrow control for jumping from one related marking to the next.

Explore the various marking systems described in the user manual, in Chapter 18. Most of these are capable, some quite simple in their usage, and all can be very precisely targeted with the various searching tools.

So while Scrivener does lack a webpage or word processor style mechanism for linking directly to a chunk of text with a single click, hopefully you’ll find something in here that works for you, that provides that same capability. In my opinion, even if I had the option to create a simple direct hyperlink, I probably wouldn’t use it much, because I really like being able to describe what an editing link like this is for. Simple hyperlinks have none of that, they are just blue text you click on.

Notes as Files

Next, we’ll explore some practical techniques that take advantage of the concepts described above.

So I’d love to be able to go into my revisions/notes document, and have a link to a specific section of text in chapter 1 that I can click on and will take me to that section of the document. It seems like I can do the reverse of that - highlight text in chapter 1 that will take my to my revision document, but it doesn’t go both ways.

Now as to specifically what it sounds like you are doing here, there may be a dedicated mechanism in Scrivener that was designed for just this sort of thing, which in turn has a byproduct of giving you a “hook” to finding a specific spot of text:

  1. Select the text that you wish to remark upon.
  2. Hit ⌘L, or use the Edit/Document Link/New Link... command, if you prefer the mouse.
  3. Leave the name as generated, and select where you’d like to gather notes for this chapter.

And off you go. See what’s going on here? Every note will have its own individual document, and most often you would create a folder for each major section (such as a chapter) that serves as a listing of all the notes about it. Click on that folder and you’ll get the notes as a corkboard, outliner or Scrivenings session. These notes can be organised, tagged with keywords or other metadata, and even selectively compiled if that is what you want.

Tip: what happens when you create a new link is up to you. Settings for this are in the Behaviors: Document Links preference pane. The Copyholder option has become my favourite over time, because it leaves me free to continue writing and editing in the original context, if that is what I want, or I can very easily jump into the copyholder with ⌃⌥⌘D and type in my thoughts.

So how do you get from that, to what you want to be able to do? Since we are leaving each note’s name as the linked text itself, we’ve got everything we need to find that text again easily, from the note. Try this:

  1. From the note, hit ⌃⌥⌘T to shift the cursor into the title field.
  2. Press ⌘C to copy, ⌃⌥G to open Quick Search, and ⌘V to paste.
  3. You’ll get two results—one being the note itself of course! What you’re interested in is the result in the “Text” section though. Select that, punch DownArrow + Return, and the item will open with you scrolled right to the text.

If you’re a fan of macros, you may note how this procedure is quite predictable. If I used this technique a lot, I’d probably set up a single hotkey, like F8 that does all of the above automatically.

Keeping Change Logs

If I’m overcomplicating and there’s an easier way to do this that would be great! But I’d love to be able to look at one document that has a list of things I want to change that is linked to the text I’d like to change.

Now this is something I do a lot of in some of my projects! Each revision might impact a broad swath of items in the Draft folder, and I like to have a central nexus where I can jot down why I’m making this change, make little todo lists of things I’ve thought of that might be impacted, and so on. In short I like to document what I’m doing for the sake of my future self.

I have a top level folder in the binder for “change logs”. Within that is a list of sub-folders, each collecting milestone revisions in the draft as a whole. Within that are the specific notes on edits that were made, as individual binder items.

You may well be thinking that the previous tip would be a great way of building this list of change notes, and you’d be right! With one small adjustment, my approach while working through the text is: when I spot something that needs fixing, I create an inline annotation, and type a phrase to identify this edit to myself, as a link. This link won’t be seen in the output, nor will its text, thanks to the inline annotation. The New Link tool remembers the last place you filed a note, and uses the linked text as the name of the note by default—so for me I never even look at that dialogue, I just punch the Return key.

That’s how I create a new entry in the current milestone folder, but to insert another related edit marker elsewhere, sometimes I will use Quick Search to look up the log file and drag it into an inline annotation to link it into the text. But more often than not, thanks to the Copyholder workflow I mentioned above, I’ve already got that log on my screen. I can be updating my notes about the editing process for it as I work through the manuscript, and I can drag the icon out of the copyholder header into the main text editor to create a quick and simple link.

Using Notes as a Nexus

An important ingredient to this workflow (and many others for that matter) worth bringing up is the Bookmarks pane. If you’ve been trying out this technique as I describe it, then navigate to the change notes item using whatever method you prefer, and open the Bookmarks inspector tab. Each time you linked to this file from anywhere in the Draft, Scrivener recorded that action as a bookmark. You have an automatically generated list of areas within your draft that relate to this specific edit. A year from now, if you need to change another thing that relates to this particular aspect of your work, you have a “to do list” all ready to go!

You can of course also add bookmarks by hand, which I sometimes do instead. It depends on the kind of edit I am doing, as sometimes I want a back-link from the manuscript to each change log file that has impacted it over time. Often, since my chunks of text are so small, I don’t need an inline annotation. So in that case I drag the Copyholder icon to the Bookmarks list rather than into the text—that’s all it takes, and doing so creates a back-link from the nexus as well, so they both refer to each other in that same list.

And again, that preference pane I referred you to is where you can tweak how bookmarks and links work. Myself, I prefer to use these tools for navigation, so “Current Editor” is what I set them to. But for chapter notes, any of the other options are best for a referencing approach vs navigation.

E.g. if you use “Other Editor”, and load all of your chapter notes into the other editor as Scrivenings, then clicking on links or activating bookmarks scrolls the editor to that note. You basically get exactly what you’re looking for with that combination of settings and features, and with very low overhead. You’re letting Scrivener do all of the hard work of building lists of notes, back-link lists and so forth.

Using Snapshots to Identify Edit Points

I could mark each edited piece of text in a section, but more often than not I’d rather just have one link or bookmark and let Scrivener handle the dirty work of tracking the edits down to words and sentences. Here’s how you can do that.

When you are done editing a section and are ready to move on to the next, create a titled snapshot, the via Documents/Snapshots/Take Snapshot with Title command, pasting in the edit log’s title.

In this hypothetical year from now, you can jump to this specific chunk of text in the Draft from the nexus note, open Snapshots, select the related editing marker along with the previous snapshot, and hit the Compare button. This will compare the changes made between the one you marked, and the state of the document the last time it was edited (if you use this technique religiously, you’ll have a tidy list of edit logs as snapshots for each item). You can also see all changes since then, by only selecting one snapshot of course.

And that’s why I don’t bother doing the manual labour myself! :slight_smile: Just get me into the generally correct part of the binder, and let Scrivener handle the rest.


One small mention here, but for some small notes, the above is a bit overkill. I’m sure you’ve already explored them, but the Inline Annotation and Comment features, in the Insert menu, are often the best tool for the job, and are by their very nature bound to specific pieces of text.

But, for long form notes and more complex organisation techniques, nothing beats Scrivener’s pure outline based approach. You will run into limitations with simple notational text, like being unable to gather them by kind in search results, etc.


This thread seems to address something I’d like to do: enable links from my book’s text to corresponding entries in a glossary. Scrivener enables bookmarks at the file level, but not at individual text locations, yes? Can inline annotations be adapted to this usage? I’ve tried this, but can’t see how to link to an annotation rather than a file. TIA.

I am thinking that a glossary section is precisely the sort of thing it would be perfectly natural and advantageous to split into individual documents in Scriv — one per glossary entry. Then targeting files is all you need.

That would be an elegant solution for a normal glossary! But mine has hundreds of entries, so I’m reluctant to create that many files.

Would you create a hundred lines in a text file though?

There is perhaps a psychological hurdle of thinking in terms of the text entries in your binder outline as being files. It would of course be absurd to create hundreds of actual files on your computer for a glossary, but nothing in Scrivener really maps to that specific concept internally. I would go so far as to say that it is rather unfortunate, and perhaps ultimately confusing, that we refer to the indented lines in the binder outline as “documents” or “files” at all, never mind “folders” being in the mix too. It just brings a lot of Finder/Explorer based mental baggage over that is wholly irrelevant, and in fact largely fictional.

Indeed, if you don’t type into the main editor, they never even become actual files at all, they are in essence much closer to my original assertion: they are in fact lines in a file—the binder file in this case. But really you shouldn’t concern yourself with whether your use of the binder’s features generates literal files or not—Scrivener can take it, and it’s probably making more files than you realise all the time (like how typing into index cards creates .txt files, and using a style creates a file for every chunk of text you use styles in, etc.).

I have projects with many tens of thousands of literal files in them, which map back to binders that have thousands of entries. It doesn’t break a sweat, and it won’t even notice your list of several hundred. :slight_smile:

Seriously, the only time I’ve encountered a case where someone had “too many lines in the binder” is a project we were sent in where it looked like the user had tried to download vast chunks of Wikipedia into the project, and had hundreds of thousands of entries. Even then, it was more a case of how much the computer could handle, rather than the software itself. It was handling it just fine, only very slowly, because that’s an idea perhaps better deferred to 2035’s hardware. :laughing:

Anyway, if you want to see a real-world example of this in play, download the Scrivener user manual project and jump down to the Menus & Keyboard Shortcuts appendix. You could turn on View ▸ Outline ▸ Show Subdocument Counts in Binder as well, but with a little poking around, you’ll see that this 71 page appendix, which is incidentally formatted much like a glossary would be, is in fact comprised of over 500 “files”—one for each command! Overall though, the structural design of that project should serve as a demonstration that the binder is a large-scale hierarchical outliner not a file manager, and it is meant to be used as such.


I agree. IMO, many difficulties that people have with Scrivener come down to reluctance to embrace the idea that Binder items can be really small, and it’s okay.


1 Like

Amber, muito obrigado for sharing your strategies. I will be using the copyholder a lot more now that I know it exists :slight_smile:

Um prazer!

Hi everyone.

This is my first post, I think. I wanted to share my use case for Scrivener and advocate for implementing the possibility of interlinking chunks of text between separate documents.

Use case:
I am using scrivener as a translation tool. Not in a computer assisted / automated kind of way (with translation memories, glossaries, segmentation etc), but for literary translations, where those things aren’t needed / helpful anyway. It is more akin to writing somethin myself, just with the difference that I always have two documents open at the same time (two editor windows, horizontally separated; I use a Dasung Paperlike e-ink monitor, so screen space is limited; works very well). Scrivener has been my main text editing / translation tool for several years now. It is great for keeping everything in one place / file (source text, target text, research notes etc.)

Problem / Request
The only time I find it lacking is during proofreading a raw translation, since there is no way to interlink specific portions of text / sentences / words within separate files (i. e. original text <-> translation). I have to constantly scroll two documents, which can be very distracting, instead of just jumping to where I need to check back with the source text. (I have enough experience to know when there is a need to double check / reconfirm something during proofreading,) My workaround right now is using tons of comments with copied text, but having direct links would be soooooo much better. Creating documents with tiny portions of text wouldn’t make any sence in this context.

I hope there’s a way to implement it some time. There seem to be quite a lot of people requesting this and I wanted to add myself to the list :smiley:

Cheers and thanks for creating this great software!

1 Like

Sorry, I hate to just link to the very same thread, wherein I explained methods one can use to do what you’re trying to do, but I’m not sure what else to do. :laughing:

It might be helpful if you indicated which of the techniques you attempted to employ, and if so, what aspects you found wanting, rather than rephrasing the original query which lead to the discussion.

Hi Amber,

I’ve read your detailed post and considered the workarounds you kindly suggest, yet they are not practical = timesaving in my use case. I only would need quick and oftentimes only temporary links between two portions of text, without altering the document structure or creating an intricate system of cross-referenced markers. So I am still hoping this feature will be natively supported at some point in the future,.

I get that this might be very difficult from a programming standpoint. But the feature itself, from a user’s perspective, is quite simple. Would it be of geat convenience? Sure! Am I willing to spend hours finding / implementing elaborate workarounds? Probably not.

The intent of my post was to highlight a use case in which direkt text links between documents would be very welcome and advocate for its implementation, not to ask for methods to achieve it. I know that pretty much everything can be done with specific markers and a solid search function. Still, if I was happy with such solutions I wouldn’t be using Scrivener instead of a simple word processor, like most of my colleagues do.

I don’t want to sound snarky, I appreaciate your suggestions and the enthusiasm with which you try to help. [heartemoji] Stay that way!


1 Like

How about enabling line numbers? View → Text Editing → Show Line Numbers. (Doesn’t work in Page View.) They don’t create a link at all, and therefore require no advance preparation on your part and leave no “mark” that you then need to remove. But they allow you to quickly and easily go back and forth between the same location in the two parallel documents.

The actual connection will be between paragraphs, not individual lines, as Scrivener only increments the line counter at a paragraph break, but that may actually be an advantage for your work, as I imagine the line count varies more between languages than the paragraph count does. And in any case you can insert a new line whenever you want if you need more granularity.


1 Like

Steps 1 and 2 are predictable, but step 3 is not. It can turn up any number of matches for the original text. I don’t see how DownArrow + Return is of use, either. The link source opens when I select it.

Yeah, I would imagine if one were interesting in automating this a bit, they would make use of the ability in such a way that it tends to produce better results than your single-word example, particularly if the word is fairly common in the project. By that I mean, selecting “incandescent dragon” and making that the title of your note may be unique enough, but the more text of relevance you select the better it will tend to work of course.

I haven’t looked into it, but there may even be a way to make the macro aware of overloaded cases like this and bail out—maybe checking for subwindow height or something. That way it works on simple ones and leaves it up to you to point and click otherwise.

Sure. No problem to make the text more unique, but I was surprised to see the matches were not in order.

The title matching area may not be in binder order. There is some weighting that is done behind the scenes to elevate more likely matches—in this case because the search term precisely matches the title of a document from end to end, that’s considered a more likely target than others. There are a few other “fuzzy” considerations like that, as I recall. This also helps keep what you’re looking for in the title list to begin with, never mind easily accessible, since the list is capped at ten.

I mean the text matches are not in order, but sure. It can be complicated.

Oh okay, I had thought only the titles had some fuzziness to them, but there may be more going on behind the scenes.

Hi AmberV,

Is there a Scrivener tutorial that follows your excellent treatise on referencing within Scrivener documents, particularly regarding the section on “Marking and Navigating to Any Text Precisely”?

Thank you,