# Spacing around \left and \right

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

• 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, 2010 at 23:16
• 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, 2015 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:

\let\originalleft\left
\let\originalright\right
\renewcommand{\left}{\mathopen{}\mathclose\bgroup\originalleft}
\renewcommand{\right}{\aftergroup\egroup\originalright}


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, 2010 at 1:13
• 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, 2010 at 2:37
• As result of the newsgroup thread I had written package mleftright. It also adds some error checks (group nesting levels). Aug 5, 2012 at 17:05
• What about $y=\mleft[x^2\mright],$ vs. $y=[x^2],$? Why is there a difference? Feb 22, 2013 at 21:17
• 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, 2014 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)
• 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, 2018 at 1:52
• Shouldn't it be \bigl(x\bigr) instead of \bigr(x\bigl)? May 9, 2019 at 13:51

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

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

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

\let\originalleft\left
\let\originalright\right
\def\left#1{\mathopen{}\originalleft#1}
\def\right#1{\originalright#1\mathclose{}}


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.

• 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, 2010 at 3:46
• 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. Sep 1, 2010 at 4:29
• 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, 2010 at 12:42
• 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... Sep 1, 2010 at 15:36
• Of course. I just thought it was obvious that I took the code from you. Sep 2, 2010 at 2:25

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:

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

\documentclass{article}

\Umathopinnerspacing\displaystyle=0mu
\Umathopinnerspacing\textstyle=0mu

\begin{document}

$\cos(\theta)$

$\cos\left(\theta\right)$

\end{document}


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.

\def\delim#1#2#3{
\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.

• How do you use \delim? From what I can tell, it doesn't work in an align environment because an error occurs when you include \ inside \delim. It also doesn't seem to work for automatic line breaking when using inline text. May 16 at 19:09
• @PaulWintz \delim{(}{\frac{1}{2}}{)}. You should define other macros for parens, brackets, etc. based on this. I just tested this again on overleaf and it does make the delimiters behave as if they are just \bigl \bigr etc. so that the spacing around operators can still break lines and expand/shrink to justify text. And no, it won't work if you put a line break in the middle of it in align mode. 17 hours ago