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.)

  • 9
    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??? – j_random_hacker Oct 26 '10 at 23:16
  • 9
    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. – alex.jordan 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.

| improve this answer | |
  • Can you give an example of where \right)\mathclose{} gives you better spacing? I don't see the application here. – Will Robertson 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 – Mateus Araújo Sep 2 '10 at 2:37
  • 30
    As result of the newsgroup thread I had written package mleftright. It also adds some error checks (group nesting levels). – Heiko Oberdiek 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)
| improve this answer | |
  • 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
  • 4
    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.

| improve this answer | |
  • 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. – Mateus Araújo 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. – Mateus Araújo 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. – Mateus Araújo 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).

| improve this answer | |
  • 5
    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 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.

| improve this answer | |

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

| improve this answer | |

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.

| improve this answer | |

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.