When you press Page Down in a browser, there's usually a small number of lines from the bottom of the current windowful displayed at the top of the next windowful. The amount of this overlap is different according to the browser being used (given a particular font size, of course). In the *nix "less" command, the default amount of overlap is zero, but this can be changed by the user. Zero is what you get with a printed book or newspaper too, of course.

Are there any published guidelines on what the amount of overlap should be, or studies on the topic?

Update: Thanks to everyone for their contributions.

The issue which prompted my query is with WebKit. I've posted about WebKit-based KDE browsers here: https://forum.kde.org/viewtopic.php?f=15&t=108930&sid=c585b1db933e0c0be00ccd27a67e3638 and about Chrome here: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/ZQjrFKfMOrY.

WebKit changed about three years ago, I've found. In the WebKit bug report which documented the increased overlap, someone commented that some Chromium people were considering subtle graphical effects apart from overlap which would cue the user, such as a slight lightening or darkening of the scrolled-in page region that would then fade away: https://bugs.webkit.org/show_bug.cgi?id=32595#c16

I think it would be cool for paging to work so there were never partial lines at the bottom of the window with just the top parts of the letters showing. E-book readers get this right, but then they're generally dealing with simpler content.

  • 3
    +1 Hmmm... an interesting question, a good deal of novelty to it. Personally I appreciate the overlap. I believe it has to do with keeping the perspective and distance to what you're reading. You don't want the perspective to be skewed (angle between your face and the text you're reading), and you want to read from a specific distance. With printed material this is easy to control by simply moving the material with your hands, a computer screen is not shifted as easily. I think that is why there is overlap, to keep perspective and distance constant. I don't know any rules for it though. Nov 6, 2012 at 11:59
  • Plus it's also easier to orientate where you are in the text if you get to see some of the content from before paging down. Nov 6, 2012 at 12:01
  • 1
    We can debate the overlap amount but so far as I know we have no control over it... Thus what is the actual question?
    – scunliffe
    Nov 6, 2012 at 13:09
  • 1
    What's the point of knowing this? Are you creating a browser?
    – dnbrv
    Nov 6, 2012 at 13:33
  • 1
    I'm asking because I've raised a bug report on an open-source browser because I think the amount of overlap is too great. I'm hoping for further justification. Nov 6, 2012 at 14:27

3 Answers 3


That is very individual for each browser, and it keeps changing. Opera had no overlap until version 12, where there is a tiny overlap (which upsets long time opera users). Internet Explorer uses 10% overlap which is a huge overlap, especially on low resolution screens. Safari scrolls down an entire page “minus a small overlap”. But as far as I know – there are no numbers to follow.

This is of no real concern to super users, since they do their own personalization of the browser. But for other users, we need to address what issue the overlap is trying to address. Most likely an overlap is present at default for the reason that the user should not loose context when performing [PgDn]-button operations scrolling down a page.

To those who reads a text, an overlap of one row of text would be enough. For “Facebook scrolling” post by post scroll would be the best (as they do it in Google+ using the buttons J (down) and K (up). But if you need a percentage I’d use 5%, which is approximately 38.4 pixels on a 768 pixel high screen. It’s well enough to cover the last row of text from the previous “page”, but not annoyingly high that users lose focus because of a too large overlap.


It very much depends on content. The optimal amount by which to display is just enough but no more than necessary.

But what defines 'just enough' and just enough for what.

Just enough to be able to relate the content on the next page to that of the previous page.

Just enough to be able to locate the next exact point of interest that follows on from the previous point of interest.

Just enough to visually confirm that if you were mid paragraph, there is a little bit of what you were just viewing that was the same content and that you are indeed at a point which is related to the end of the previous view.

Just enough to be able to see the whole of something without having to scroll or page back up to see the rest of it.

So this is in a way related to the chunking of information on a page - and the flow of information on a page.

If you're reading text, then it should not be so much overlap that you have to seek a long way down the text on the page to find the continuation point. So for example a couple of lines should suffice so that the context and 'just read' lines can be easily omitted. Less than that and you cannot determine that you really are where you left off.

It's important to have that transition content there to tie the two pages together. You see this on maps (especially real paper maps) where there is just enough overlap that if you were following a road or terrain as you go off the edge of one page, you can recognise a small section of it on the relevant edge of another page.

The brain is very good at building and recognizing patterns, and when you move from one page to another, you are not typically re-reading the text that you just read, but you are looking for that pattern of words you just scanned so as to be able to limit the flow of reading. Too much information and the flow is interrupted because you don't recognize the pattern. Since we read text one line at a time without having to follow with your finger from the end of one line to the beginning of the next then we're very used to chunking the lines. And that means we should overlap at the minimum by one complete line of text.

If we're looking at images, then clearly it could be useful to detect this and page down such that we see the next whole image or block rather than having it cut off at the top.

However - that's not the whole story, because we don't necessarily read text right to the bottom of a page before paging down. We actually are looking quite a lot further down the page than at first we think. we like to see a whole paragraph on the page so that we can process what is clearly a whole chunk without interruption. We also detect broken lines where we can only see the top half of a line of text at the bottom, and that's distracting too, so we might well scroll or page down in order to distance that from our current point of interest. Note that reading devices will never display halves of a line.

So you need to cater for those cases where we don't read to the bottom completely, which means that if we page down, we need quite a decent amount of overlap, and in fact 10% of a page may not appear odd in those situations.

It's a fine line, therefore, between overlapping enough to relocate a point of reference at the same granularity as our current chunking granularity, and overlapping so much that the point of reference we're looking for is too far down.

And that's where I came in - it depends on the type of content - but also much more subtle stuff such as the likely engagement of the reader; the likelihood of the user to be consuming the content sequentially or more randomly; the font sizes; the paragraph breaks; the visibility of the end of a paragraph or the completeness of the display of the bottom line (and the top line after paging).

Clearly, the page down mechanism is going to have to work hard to get it right all the time given the number of variables working together here, and it's a next to impossible task. So there's a middle ground which I'd suggest is somewhere between 2 and 6 lines of text depending on the relative height of the window to the screen.

These are just my considered thoughts on the matter - perhaps someone else will find a paper on it.


To find more recent (mid 1990s to mid 2000s) research that might help, search both the ACM digital library and IEEE for 'visual momentum'. The concept originated with David Woods at Ohio State - or the most recent research on visual momentum as applied to HCI originated at OSU. Starting with visual momentum should point you backwards, chronologically/conceptually, to related ideas and research.

  • Have you searched that one by yourself, too see if you can answer OP Question? Nov 7, 2012 at 7:49
  • Unfortunately, I cannot answer the question. I can only suggest a starting point for finding an answer. I read much of the research on visual momentum from that period when it was first published but do not remember enough of the details now. In this situation, the details matter. For example, window size, task type, and information density affect the answer. I am certain visual momentum is relevant but I would have to reread the research to answer the question with confidence. Nov 7, 2012 at 13:47
  • It would be really good to give actual links, but this is a good starting point. Nov 7, 2012 at 21:46
  • 1
    Link1 Nov 7, 2012 at 22:51
  • 1
    Link2 Nov 7, 2012 at 22:52

Your Answer

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

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