I started using showkeys in one of my documents and see this error

\pdfendlink ended up in different nesting level than \pdfstartlink

A bit of google suggests that this "happens when hyperref is used under pdftex and a citation splits across a page boundary". (See: http://tug.org/errors.html).

But this package is only useful at drafting stage where the text is changing frequently i.e. the chance of the error is high. Is there a general way to smoothly use showkeys with hyperref? Thanks.

  • I've never had a problem using showkeys with hyperref, although the hyperref documentation claims that they aren't completely compatible, and the hyperref author is not willing to fix that. I load showkeys before hyperref, which may be relevant. I think you need to give us a minimal test case.
    – Lev Bishop
    Aug 11 '10 at 14:22
  • The thing about the minimal example is that it is not easy to construct but I will see if I can come up with something.
    – Leo Liu
    Aug 11 '10 at 15:59
  • you can use the lipsum package to get some dummy text to construct your minimal example. (Or simply accept Charles' answer below.) Feb 25 '11 at 19:35
  • @LevBishop This is strange; from the way showkeys works I'd have guessed the other way round (modifications to \label by showkeys must come after hyperref). Nov 20 '12 at 5:12
  • For reference, the correct solution is given by tex.stackexchange.com/a/65224/3406 (I think). The problem disappeared for me once I updated hyperref as described in that answer. The corresponding question also has a MWE. Jan 4 '14 at 19:07

10 Answers 10


I figured out the location of the link causing the error using the [draft] option in the hyperref package definition, as explained in this 2002 mailing list post by James A. Bednar:

... when this error occurs, write down the page number where pdflatex aborted, then add the "draft" option to hyperref:


and recompile the document. PDF output will now be generated, the problematic link should be the citation whose latter half begins the page where pdflatex aborted. After slightly rearranging the text to avoid the linebreak, the [draft] option can be removed.

(I tried user22326's useful suggestion to use the [debug] option in the hyperref package definition, however, this didn't help me in finding the location (in the log, or in the latex file) of the link causing the error. Not even after I figured it out using the draft option solution.)

  • 5
    This definitely worked for me, and seems to be the best way to proceed with this issue that I encountered many times.
    – jibe
    Aug 12 '14 at 7:55
  • 1
    Instead of rearranging the text, one could "repair" the boxing/nesting level of the closing \pdfendlink. See this workaround .
    – AlexG
    Jun 1 '17 at 8:21
  • What if we do not rearrange the text and just go on with the draft option?
    – lonesome
    Jul 13 '17 at 4:11
  • 6
    In my case, hyperref is loaded by the class file so set I the draft option using \hypersetup{draft} in my preamble.
    – Warrick
    Jan 22 '18 at 8:51
  • 2
    Got stuck with this answer for a while. It seems to be working for everyone, UNLESS the broken link is in the bibliography! For that case, another solution below worked like magic: tex.stackexchange.com/a/449633/23048 !
    – Dr_Zaszuś
    Mar 7 '19 at 16:57

I have just resolved a similar error by putting the offending citation inside an \mbox. You just have to figure out where is the offending citation, for example, by successively commenting and uncommenting your LaTeX file. It worked for me, so I hope this works for anyone else, as unfortunately, the error message is not helpful (as usual in LaTeX).


I use an alternative, which gives a better rendering to me:


It prevents breaking a citation across two pages. Hence, hyperlinks in a citation cannot be broken. It solves two problems at the same time for me.

  • 4
    Wow! This is really a life-saver!
    – Dr_Zaszuś
    Mar 7 '19 at 16:55
  • Resolved the problem for me too, thanks for the posting!!
    – Leo Simon
    Dec 30 '21 at 22:42

Sometimes, the links are created by the bibliography, from items with URL fields. A solution that helps in this case and preserves clickable links is to make sure that each \bibitem is typeset without column or page breaks:


A \vfill rubber length is inserted before each \bibitem. This produces ugly output that is nevertheless "good enough" for a draft. Don't forget to remove this hack just before releasing the document.

(For a general solution, we also need to Wrap natbib macros \citep and \citet. No luck with this one yet.)

  • This was the problem in my case. I've just removed the URL entries in the bib file and the error is gone.
    – BloodyD
    Aug 17 '20 at 15:47

Without an MWE, it's hard to say something that we can be sure will fix the problem. I haven't, for the obvious reason, tested any of what follows.

If the problem arises when:

  1. showkeys is used near the end of the document, then you can force a page eject if the command is used near the end of the document. E.g.: \let\urshowkeys=\showkeys \def\showkeys{\needspace{5ex}\urshowkeys} (requires needspace package).
  2. Likewise if it occurs when a hyperref is used near the end of the document.
  3. If it occurs because the link is split between the main body and the margin text, then the best thing might be to write your own wrappers that puts the label in the body text, so that the problem doesn't arise. This should be easy, and I'm guessing this is an acceptable workaround given that the text is a draft.
  • 3
    This entry was very helpful but failed to let me know how to find the problematic citation when using multiple files (pdflatex wouldn't point to the right line). Although trivial, this might save some time to some users out there. Use the general option [debug] in the hyperref package and go through the pdflatex log to find the exact citation that is causing the problem. Cheers!
    – user22326
    Nov 20 '12 at 3:36
  • 1
    For this wondering about it, MWE = minimal working example. Nov 29 '13 at 9:20
  • @user2236: the [debug] approach seemed promising, but I couldn't find any clues in the log. I've inserted an answer using the [draft] option instead. Jan 15 '14 at 10:16

Place \hypersetup{draft} before \begin{document} will solve the problem.

  • 6
    This would defeat the purpose of loading hyperref
    – egreg
    Apr 1 '17 at 22:05
  • 1
    It really works!
    – Derzu
    Jul 13 '17 at 17:56
  • Thanks for this! I needed this option due to a conference template that I couldn't alter pre-loading hyperref. Dec 15 '17 at 1:03
  • worked for me too!
    – Daniel
    Feb 15 '18 at 6:55
  • 1
    While this works, an explanation would be nice.
    – runDOSrun
    Sep 13 '18 at 12:15

See this issue. A workaround is to let links break across pages by adding this to the preamble:

\patchcmd\@combinedblfloats{\box\@outputbox}{\unvbox\@outputbox}{}{\errmessage{\noexpand patch failed}}
  • Works for me (although a little bit more explanation would help to know what it actually does)
    – Spock
    Oct 12 '18 at 10:37
  • Worked for me, but yeah, could we have more explanation ?
    – matthieu
    Jul 12 '19 at 12:59
  • This indeed seems to fix the problem, at least in my case, without having to disable hyperref altogether or messing up the layout of my document. For the record, the issue referred to seems to be a bug in an old version of hyperref (which the machine onto which I’m compiling has).
    – tb87
    Oct 6 '21 at 19:38

The following two lines in the preamble solve the problem:

  • \hbox also prevents that the link is broken across lines. Nov 2 '16 at 21:59
  • This doesn't help at all...
    – durka42
    Jul 24 '18 at 7:56

In my case, the problem was a reference that was stretching over two pages like Miller (2019) where Miller was on page k and (2019) was on page k+1.


In one case the offending link seemed to be coming from the bibliography link generation. This might help:

sed '/\\bibitem/ s/ /~/g' file.bbl > tmp.bbl && mv tmp.bbl file.bbl

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.