Why does the addition of a \left and \right introduces an extra space around the formula? Specifically, why do $\cos(\theta)$ and $\cos\left(\theta\right)$ render differently?

Is there a way to use resizable delimiters without introducing the spurious spaces?

Why did Knuth design it like this?

Edit: This occurs too, if \operatorname{MYOP} or some other operator, like \lim, \min etc. is used. (This edit is basically to make it easier to find this answer.)

  • 10
    Yes, this is infuriating... Prevents me making a single command for Big-Oh notation that can handle both simple and tall formulae. How on earth was this overlooked??? Oct 26 '10 at 23:16
  • 10
    Not sure if it helps in all cases, but $f{\left(x\right)}$ loses the extra space. With an operator like \cos instead of something simple like f, additional braces around the operator are needed to kill the space: ${\cos}{\left(\theta\right)}$. Not as good as answers below, but nice to know if you aren't able to change preamble. Mar 4 '15 at 6:49

I've found an answer in a usenet post by Heiko Oberdiek and another by Donald Arseneau. Improved code thanks to shiznick.

The issue is that \left and \right introduces an inner atom (see The TeXbook, chapter 18, section 4), which has different spacing rules than ordinary atoms, produced by ( and ) (and the other delimiters).

To remove this spurious spacing, one has to manually insert opening and closing atoms in the formula. Specifically, $\cos(\theta)$ and $\cos\mathopen{}\left(\theta\right)\mathclose{}$ render exactly the same.

However, inserting it does make your formulas ugly. So a good solution would be to just redefine \left and \right:


Incidentally, this code also fixes the spacing of |, that is very fragile. Check for example $|+x|$ and $\left|+x\right|$. Also $\cos|\theta|$ and $\cos\left|\theta\right|$. This is due to the fact that both delimiters are equal, and TeX doesn't know if they're opening or closing the expression. The same logic applies to \|.

EDIT: The old code had a problem with subscripts and superscripts: they didn't accompany the growth of the delimiters. Fixed now thanks to Philipp Stephani and Heiko Oberdiek.

  • Can you give an example of where \right)\mathclose{} gives you better spacing? I don't see the application here. Sep 2 '10 at 1:13
  • 2
    Of course! The line where I first noticed the bug: \[\ket{\psi} = \alpha \ket{0} + \beta \ket{1},\] the \ket macro is \newcommand{\ket}[1]{\left| #1 \right\rangle} which was giving too much space between the \rangle and the comma. Also, this question: tex.stackexchange.com/q/2401/1035 Sep 2 '10 at 2:37
  • 34
    As result of the newsgroup thread I had written package mleftright. It also adds some error checks (group nesting levels). Aug 5 '12 at 17:05
  • What about $y=\mleft[x^2\mright],$ vs. $y=[x^2],$? Why is there a difference?
    – letmaik
    Feb 22 '13 at 21:17
  • 3
    What are the limitations of this approach? Are there cases when it is not recommended to apply this workaround? Or is it something that can be safely added to all preambles?
    – Dror
    Jan 12 '14 at 14:08

The package mathtools has implemented a general solution for that problem. It defines the command \DeclarePairedDelimiter that you can use as follows: \DeclarePairedDelimiter\parentheses{\lparen}{\rparen}.

With this single declaration you have a new powerful command for several cases:

  • \parentheses{x} just replaces $(x)$
  • \parentheses*{x} will do the right thing with \left and \right (same result as the answer of Mateus Araújo)
  • \parentheses[\big]{x} which replaces $\bigr(x\bigl)$ (all the size commands work)
  • 5
    I've run a few cases with 'mleftright' and 'mathtools', and the results seem identical. The code in 'mathtools' seems to have greater flexibility, although 'mleftright' includes some additional checks for error conditions. Is there a reason to prefer one of these rather than the other?
    – John
    Sep 10 '18 at 1:52
  • 7
    Shouldn't it be \bigl(x\bigr) instead of \bigr(x\bigl)?
    – L. F.
    May 9 '19 at 13:51

The following code fixes both \left and \right -- put it in the preamble:


I haven't tested it in all scenarios, of course, but I added it to the preamble of my entire Ph.D. dissertation, and it worked without errors and without any additional modifications to the code.

  • 2
    It makes me somewhat nervous to use macros to mess around with delimiters; they have their own unfathomable rules of spacing. The simpler, the better. But I liked your idea of actually fixing \left and \right instead of just defining new commands. Sep 1 '10 at 3:46
  • 1
    It makes me nervous, too. I think this is about as simple as it's going to get (although I'm happy to be proven wrong). The fact that such a long and complicated 200-page document TeX'ed without incident with these changes (and no others) gives me hope that they are minimal and robust.
    – shiznick
    Sep 1 '10 at 4:29
  • 1
    Okay, I have an error (again due to Arseneau): $\left \delimiter "4266308 8,9\right \delimiter "5267309 $ Its not an spacing error: your macro fails to realise that \delimiter "5267309 is actually just one character. Sep 1 '10 at 12:42
  • 1
    Yup. Agreed. The code you posted works where this code fails, and semantically it probably is better. (I now know about \aftergroup! :) On the other hand, you made improvements to that code based on the code I posted here and didn't mention this fact in your revisions. I'm happy to work toward the same goal of improving the code, but a short line like "(Thanks to shiznick for the suggestion of using \let.)" really goes a long way. It might even earn you another uptick...
    – shiznick
    Sep 1 '10 at 15:36
  • 1
    Of course. I just thought it was obvious that I took the code from you. Sep 2 '10 at 2:25

"As result of the newsgroup thread", which was mentioned in Mateus Araújo' answer, Heiko Oberdiek wrote the mleftright package. "It also adds some error checks (group nesting levels)." (both cited from Heiko's comment to Mateus Araújo' answer)

\mleft and \mright from that package can be used instead of \left and \right and do not insert additional space.

When additional space shall not be used, also \left. and \right. should be looked at (see What does \right. do?). To get rid of the additional space there
\left.\kern-\nulldelimiterspace and \right.\kern-\nulldelimiterspace can be used (probably best by defining those as new commands and using those).

  • 6
    Are there any drawbacks to using your versions of \left and \right? Why aren't they the default in TeX?
    – Friedrich
    Mar 30 '15 at 14:56
  • This should be the accepted answer, not some ad-hoc macro.
    – James
    Sep 19 at 21:51

This is in answer to the particular question of why Knuth designed it like this. I believe it is because opening and closing using \left and \right is often done in conjunction with sums or other big mathematical symbols. Compare the following two formulas: normalwith_fix

The bottom one is with the suggested fix from the earlier answer. In my opinion, the top one looks more balanced, which is probably the reason for the functionality being as it is.


With LuaTeX you can control the spacing between an op atom (such as \cos) and an inner atom (which is what is generated by a \left...\right pair).







enter image description here


I have been using the accepted answer for a while now, but actually I came up with something in the last few days that also gets around the issue that \left \right prevents line breaking.

  \mathopen{\left#1 \vphantom{#2} \right.}
  \kern-\nulldelimiterspace #2 \kern-\nulldelimiterspace
  \mathclose{ \left. \vphantom{#2} \right#3 }

The \kern-\nulldelimiterspace removes the spacing produced by \right. and \left..

It's not too hard to extend this to allow for \middle either.

One note of caution: I think nesting this too much will cause LaTeX to run out of memory.

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.