I'm thinking of setting the timeout on all my tooltips in a WinForms application to infinity (or an extremely large value). The motivation is that it's annoying for the user if the tooltip disappears while I'm still reading it, without providing any extra value whatsoever as far as I can tell.

Normally I wouldn't ask something like this on StackOverflow, but the overwhelming majority of all software sets timeouts on tooltips, so it makes me wonder whether perhaps there is some important consideration I'm missing? Or is this just an old convention that nobody gives further thought to?

If you would hate infinite timeout as opposed to a short timeout, please explain why.

(If you just think tooltips are a bad idea altogether then that's a separate consideration; this question is specifically about the infinite timeout.)

  • I'm guessing that the timeouts are there to suggest that people shouldn't put too much information into tooltips, similar to the 140 character limit in twitter.
    – icc97
    Commented May 27, 2013 at 10:17
  • 1
    @icc97 I'm guessing it's there because the code for tooltips was buggy and they sometimes failed to disappear when the mouse left the required area, so someone hacked in a timeout.
    – RomanSt
    Commented May 27, 2013 at 10:26
  • hmm - couldn't find anything about being buggy, but did find MS Guidlines that says you should do as you're planning. Added an answer
    – icc97
    Commented May 27, 2013 at 14:01

10 Answers 10


The Microsoft Tooltips and Infotips Guidelines explicitly suggest that you should use the maximum value possible:

For infotips, turn off the tip removal timeout. Developers: Since you can't technically turn off the removal timeout, set it to its largest value.

They do this in the Windows Explorer for image infotips (i.e. they disappear after 32s):

enter image description here

Also the title attribute for <acronym> tags in HTML have infinite timeouts - they certainly extend beyond the 32s for Windows infotips.

Splitting hairs - but you'd actually be creating infotips rather than tooltips:

A tooltip is a small pop-up window that labels the unlabeled control being pointed to, such as unlabeled toolbar controls or command buttons.

Because tooltips have proved so useful, a related control called infotips exists, which provides more descriptive text than is possible with tooltips.

An infotip is a small pop-up window that concisely describes the object being pointed to, such as descriptions of toolbar controls, icons, graphics, links, Windows® Explorer objects, Start menu items, and taskbar buttons.


I'd go with the indefinite time out. These really short ones like when you hover over your NIC's Connect Using value to see your MAC address always times out before I'm done with it and it drives me nuts. However That said I'd avoid tool tip use as much as possible. Especially if its used to show additional info like the MAC address example. Use them to explain what things mean to the new user, not display new data.

  • I don't think it's possible to set an infinite value. The reason being that the delay property is a 16 bit integer. The max value is 32767 which when rounded down is 32 seconds. Commented Sep 22, 2014 at 19:50

If you go with infinite timeout, 1) make sure to provide plenty of inactive space, 2) make sure they expire properly onMouseOut. Because the only thing more annoying than a tooltip you can't read because it expires too quickly is a tooltip that obscures an important piece of information and doesn't want to go away.

I think the most blatant abuse of non-expiring tooltips was the early Enlightenment desktop manager. EVERY desktop element provided non-expiring tooltips, and the desktop itself did too, producing a tooltip good half a screen high and wide containing a comprehensive help on all you could ever do with the desktop, except of how to switch tooltips off.


Note that using the Win32 ToolTip API (which is what the .NET ToolTip class does), you can't set an infinite timeout on Win32 (max is ~32 seconds). Actually MSDN states that you can't set a delay of more than 5 seconds, but oddly enough 30 seconds works well for me. If for some reason it doesn't work for you, there are workarounds. I think 32 seconds should be good enough for most tooltips, otherwise you'd have to roll your own (see here and here for ideas). Lastly, you should probably address the reappearing problem. For more information see the CodeProject articles here and here.

Good luck !


I think infinite tooltips will greatly benefit tooltips that are extremely long. Take a look at a typical tooltip in Handbrake (video transcoding software).


Because of the technical limitations pointed out by ohadsc, the tooltip disappears in 5 seconds. It's annoying. You can't grasp all this in 5 seconds, especially this nerdy stuff. Nonetheless, these long tooltips have helped me transition to advanced usage of Handbrake. It's much better than having to switch back and forth between a separate help document.

I see no reason for tooltips to disappear after X seconds, regardless of how verbose the tooltip is. You can't expect everyone to finish reading in X seconds. If they wanted the tooltip to disappear, they'll move their mouse a few pixels up - that's easy.

  • 4
    that's not a tool-tip. That's an instruction manual.
    – DA01
    Commented Mar 8, 2011 at 1:29

I hate tooltips to begin with -- I hate them even more then they disappear while I'm reading them.

I would say go for the infinite timeout as long as it's not getting in the way.

But overall, I think tooltips are a poor idea and they've just been dragged along "because that's the way we've always done it". The trouble is finding a nice, intuitive alternative that solves the problem of providing concise, on-demand, feature-targeted help.

  • 2
    The question specifically said that this is not about the pros and cons of tooltips, but only those of the timeout. Please consider keeping your answers relevant.
    – Timwi
    Commented Feb 12, 2010 at 22:26

There is no benefit to the timeout. Although tooltips were sporadically used before Windows 95, Windows 95 overused them and had them consistently time out everywhere. I find it most likely that everyone just copied the convention without thinking about it properly.


What can your tooltips occlude? If they don’t occlude anything, then infinite timeout is okay. Then again, if you have that kind of space to leave empty, then may be you should use something other than tooltips, such as longer more descriptive labels.

The purpose of the timeout is for the tooltip (which the user didn’t necessarily want) to get out of the way of something the user needs to see. Consider the case of a user hovering over a toolbar control trying to decide if the command is appropriate for a selected item in a document, then a tooltip appears hiding a key part of the selected item they were studying in order to decide. Timeout makes this problem solve itself. This is also one reason tooltips should have a delay.

If the tooltip text is too long to read with a short timeout, you’re kind of stuck between a rock and a hard place. If you leave the timeout short, then the tooltip may disappear while users are still reading it and they’ll have to move the pointer around and re-acquire the hotspot (and wait for the delay), which is annoying. You can increase the timeout, but that means increasing how long other stuff is occluded (and because the text is long, it’s more likely to be occluding something of interest). You force the users to move the pointer to see the stuff, and then possibly move it back to choose a command, which is also annoying. The former is probably more annoying than the latter, but, depending on the density of your windows, the latter is probably more frequent than the former –tooltips should only be used for supplemental nonessential information, which, by definition, means that users seldom need to read them.

If you have long text, the maybe you shouldn’t be using tooltips, but what are the alternatives? I can’t recommend using the status bar because users rarely notice things in the status bar since it’s far from where they’re likely to be looking. You could put empty space right under the controls that needed tooltips and dynamically display text there full time with no delay and no timeout, but you don’t always want to use so much real estate for something users seldom need.

Maybe the solution is transparent tooltips with infinite timeout –or the tooltip turns transparent after timeout to provide optimal readability at first. Cool if transparency would for once improve usability.

  • 1
    If a tooltip was in the way and I had to wait for it to time out to see something then I'd be annoyed even if the timeout is as small as 1 second, so I'd say if the timeout is needed for this reason then I'm already annoying the user anyway, and need to rethink the UI.
    – RomanSt
    Commented Feb 14, 2010 at 13:43
  • I don't have data for the average user, but MS Windows UX Guidelines recommends a 5 second timeout, which seems right around the threshold of annoyance for me. If your tooltips only have a word or two (like they should), you could test 2 or 3 seconds and see if that improves user performance and satisfaction. For more verbose "infotips," MS does indeed recommend no time out. Commented Feb 14, 2010 at 15:10

All you need is to provide a better way to get rid of the tooltip.

Ideally, a small "cross" in the top right corner of the tooltip will indicate this can be closed. (I'm not sure how easy this would be to add with Win32 tooltip API).

In addition, make sure that other attempts to get rid of it work or at least don't make me lose work. Users might try to

  • click somewhere outside the tooltip (usually safe..)
  • click on the tooltip (don't "click through")
  • press ESC (that might proove tricky or confusing)
  • other things?


  1. make the timeout dependent on the text length

  2. give the tooltip for the currently focused item its own space, where it doesn't cover anything. @JoJo posts a great example where tooltips are bad: a lot of text, and covering a random area of the screen.

  • It's best if you can position the tooltip so that it doesn't obscure anything, but I think even if it does it's still useful, as long as there is no (and I mean no) popup delay, no disappearance delay when cursor moved away, and the tooltip automatically positions below the control it's for, without obscuring any of it. There is already an easy way to close it: just nudge the mouse away! Want them all gone? Move it to the top of the screen! Easy :)
    – RomanSt
    Commented Mar 7, 2011 at 14:17

You'll probably have to roll your own tooltip. That said, I have seen people use a statusbar-like area to show hints about what buttons do. Image-Line does this in FL Studio, and the hints were really helpful, don't change if I don't move the mouse, and don't cover anything up or introduce clutter.

This might be something to consider, especially if you are going to the trouble of making your own tooltips.

  • You didn't answer the question. The OP asked for explanations of tooltip timeouts not for alternative solutions including rolling your own. Moreover, moving contextual help into the status bar is very bad UX - it's called contextual because it's in-place.
    – dnbrv
    Commented Mar 12, 2012 at 17:39
  • To more directly answer the question, it can't be cleanly done with the builtin tooltip controls because Microsoft has intentionally limited the lifetime of the tooltip (because of orpahn tooltip problems in the past). You can change the life of the tooltip to be 32 seconds (officially 5, but really supports 32 for legacy apps), but if you need it open longer, you have to either have to reopen it on the tooltip closing event, or make something else to take the place of the tooltip. Commented Mar 12, 2012 at 20:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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