I've known about this bug for a while. Weird that it still hasn't been fixed. If the \tag mathjax is not intended to be used, then why is it included as a valid command? I can't say.

Here it is: $$i \hbar \frac{\partial \Psi} {\partial t} = - \frac{\hbar^2}{2m}\nabla^2 \Psi + V(\mathbf x) \tag{This is an example of a tagged equation}$$



Here the tag is cut off: enter image description here

Android "Stack Exchange" Application

I can scroll horizontally to view the whole thing:

enter image description here

Mobile Website

I can scroll horizontally to the view the whole thing. Note that this is by the far the worst, with the entire equation off to the side of the screen. enter image description here

  • 5
    $\begingroup$ I've only used tags as labels for numbering equations. I don't know if they are designed to handle extended sentences. $\endgroup$
    – robjohn Mod
    Commented Oct 19, 2016 at 3:18
  • $\begingroup$ @robjohn - I use them from time to time in this manner in $\LaTeX$ documents at least without issue. $\endgroup$
    – Myridium
    Commented Oct 19, 2016 at 3:36
  • 1
    $\begingroup$ I honestly don't understand what kind of a display would you expect to see with a bloated tag like that? Wouldn't a suitable aligned environment be better for this purpose in TeX also? $\endgroup$ Commented Oct 19, 2016 at 9:32
  • $\begingroup$ @JyrkiLahtonen - At the least, I would expect the equation and tag to be centered. $\endgroup$
    – Myridium
    Commented Oct 19, 2016 at 9:43
  • $\begingroup$ Maybe not centered, but with the tag aligned to the right as I think it does with a short tag. I don't see any reason why it should break with a longer tag. Is there an alternative way to annotate equations easily? $\endgroup$
    – Myridium
    Commented Oct 19, 2016 at 9:51
  • 1
    $\begingroup$ I don't know why you expect MathJax to replicate faithfully everything that can be done in $\rm\LaTeX$. It's a handicapped system that is fundamentally built as a collection of hacks and workarounds. True, it works very well, but it's not a complete substitute for a fully formed web-math engine (sorry, I just read Peter Krautzberger's blog...), so it shouldn't surprise you that MathJax is literally rough around the edges, and using a long text as a tag will break something in the design. $\endgroup$
    – Asaf Karagila Mod
    Commented Oct 19, 2016 at 12:15
  • 2
    $\begingroup$ Just put some space before the text and then write your text inside \text? Like so: $$1+1=2 \quad \text{(annotation)}$$ I don't really see why you'd want to use \tag for this as it's not a "tag" in any sense (i.e. some name for the equation that you can use to refer to it). $\endgroup$ Commented Oct 19, 2016 at 12:51
  • 1
    $\begingroup$ Or you can use an align environment, as Jyrki suggests: $$\begin{align} 1+1 & = 2 & \text{(fundamental theorem of arithmetic)} \\ 2 & = 1+1 & \text{(fundamental theorem of citemhtira)} \\ \implies 2 & = 2 & \text{(QED)} \end{align}$$ $\endgroup$ Commented Oct 19, 2016 at 12:59
  • $\begingroup$ @NajibIdrissi - Thanks, that's useful. I don't understand why that right-aligns the text when the "&" character is on the left of the text. $\endgroup$
    – Myridium
    Commented Oct 19, 2016 at 17:03
  • 1
    $\begingroup$ It's for when you want to do something like this: $$\begin{align} 1+1 & = 2 & x & = w + t \\ 3 + 5 & = 18 & skdfjdsfk & = dfklsjdfklsjlksdfj \end{align}$$ i.e. align multiple equations. $\endgroup$ Commented Oct 19, 2016 at 17:33
  • $\begingroup$ @NajibIdrissi - I think I see it now, thank you! $\endgroup$
    – Myridium
    Commented Oct 19, 2016 at 17:35
  • $\begingroup$ While I agree that \tag is probably not used correctly, I can see use cases for automatic line-breaks within equation labels; I've opened github.com/mathjax/MathJax/issues/1647. $\endgroup$ Commented Oct 24, 2016 at 8:00

2 Answers 2


Here's what's going on. Equations are supposed to be centered without regard to the presence or absence of a tag, so the equation is put in a box with 100% width, and the tag is put in a zero-width box so that its contents extends to the left of the zero-width box. This makes the equation be centered in the 100%-width box regardless of the size of the tag. This also allows the equation to remain centered even if the width of the container element changes size (like in a page that has text that fills the window from left to right and you change the size of the browser window).

But this setup would allow the tag to overlap the equation if the equation were large enough and there wasn't room enough for both the equation and the tag. Ealier versions of MathJax did just that. This overlap was considered a bad thing, however, so now MathJax prevents the tag from overlapping the equation by setting the minimum width of the container to make sure there is enough room for the tag not to overlap the equation. For equations that are not centered (one of the options in MathJax), this means the minimum width needs to be the sum of the width of the equation plus that of the tag (plus a little bit of separation). But when the equations are centered, as is done here, it means that the width has to be twice the tag width plus that of the equation, because the tag starts overlapping a centered equation when the blank space on the left is the same width as the tag.

With very long tags, like in your case, that means that one must reserve a very large white space on the left to prevent the tag from overlapping the centered equation. The result is that the minimum width for the equation is wider than the text width used in the StackExchange layout, and so the equation extends to the right. Because the text width of the mobile layouts is even smaller, the equation extends considerably to the right. This is the cost of preventing the tags from overlapping centered equations.

While it would be nice if the centered equation could stop being centered at the time that the tag would start to overlap it, preventing the need for reserving the white space to the left, there doesn't seem to be a natural way to accomplish that in CSS that is available across all the browsers supported by MathJax. So this is the best compromise we could come up with. LaTeX itself doesn't have to deal with dynamically changing page widths, so doesn't run into this issue.

In any case, this is one reason not to misuse tags as annotations, and to use one of the other constructs that is designed for that purpose as suggested in the comments. These will also produce more semantically correct results, so that your mathematics will be able to be handled better by screen readers, for example. Getting something that is visually what you want but not semantically what you mean can cause problems for users who are not able to use visual representations and must rely on other technology to access the mathematics.

  • $\begingroup$ I wasn't aware that there was semantic convention with $\LaTeX$... I have always used whatever gives the desired visual output, basically. Are these conventions set up specifically for people with vision impairment? Where can I find more information on this? $\endgroup$
    – Myridium
    Commented Oct 25, 2016 at 9:45
  • 1
    $\begingroup$ Something kind of similar has popped up on Robotics: Out of question body area bound MathJax-ed matrices. Would you mind taking a look there? $\endgroup$
    – user642796
    Commented Nov 7, 2016 at 11:52

As of MathJax 3.0, the issue still seems to be there. If you need a workaround for your site and/or you have the freedom of running JavaScript after the page load, the following will fix it responsively (on all screen sizes).
What we are doing in the code is this (through JQuery):

  1. We wait for MathJax's typesetting to complete, so that all the mjx-containers get their attributes. One of those attributes is min-width. This is the culprit.
  2. We check if the value of this attribute is more than its parent's width (only for the mjx-containers which have \tag, marked by mjx-mlabeledtr), we fix it. Since MathJax likes em units, we are using those.

  MathJax.startup.promise.then(() => { // MathJax initial typesetting complete by now
        var max_width = $(this).parent().width() / parseFloat($(this).css("font-size"));
        if ( parseFloat($(this).css("min-width")) > max_width ) $(this).css("min-width", max_width + "em");

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .