We have been puzzling over where to put the submit button, on the left or the right. In researching, we noticed that many sites put buttons on the bottom right in dialogue boxes, and on the bottom left in forms.

It makes sense: in a dialogue box it seems to denote finality, being in the endpoint of the window for left–right readers; in a form, the bottom right could be in a different position relative to the rest of the form if the window is resized.

It seems to be a convention, but I don't see anyone talking about this specific phenomenon in the following questions, nor the articles referenced therein:

Should the OK/Cancel buttons be aligned right or centered?

OK/Cancel on left/right?


So, is this level of button position optimization worth it if it creates an inconsistency in button placement? Is this a good way to go?

  • 1
    I'm hearing a consensus among answers that "be consistent" is paramount. Have you encountered sites that use the split approach that Facebook utilizes? The Facebook experience feels consistent to me, even though they follow two approaches depending on the context. So, is Facebook breaking or following this rule, and does it feel like a good experience to you?
    – Taj Moore
    Commented Jun 28, 2011 at 22:57
  • And since the left/right debate has happened in a number of links above, I'd rather focus on the precise question of a split or hybrid approach such as Facebook's.
    – Taj Moore
    Commented Jun 28, 2011 at 23:43

11 Answers 11


We decided that in order to meet user expectations, it was best to put the button in the place that users expect to find it in the context of the form or dialogue they are using and with regard to the window size.

Forms tend to be left justified while the browser window can leave a ton of white space to fill up a large monitor (especially in full-screen mode). Since the users' eyes never leave the left portion of the window, we place the button on the bottom left. This is especially important for forms that use the field name above the field, with most fields lying flush left on the form (as opposed to fields to the right of their names).

Small Dialogue & Modal Windows are fixed width and tend to be small. Most contain simple phrases or questions, read right to left: having a button on the bottom right feels like both the most progressive position and the final resting place for the eye. Were the modal window large enough to contain a long form, we would probably follow the first principal for forms.

In the end, our heuristic is this:

  1. Large Windows & Forms get the button on the bottom left.
  2. Small Windows & Dialogues get the button on the bottom right.

Note the buttons on ux.stackexchange.com:

  • Post Your Answer button at the bottom-left of the longer form

  • Add Comment button to the right of a small field

Update 2015-2-26

With mobile-first responsive being the new law of the land, the button placement varies even more based on context and user expectation. Sometimes, it's in the middle, too!

  • We're now starting to just put buttons on the left for even small forms if they're inline … and more forms are showing up inline through javascript.
    – Taj Moore
    Commented Feb 10, 2012 at 0:26
  • If you have a primary action and cancel action are they always displayed in the same order? I seem to prefer having the primary on the left when the buttons are on the bottom left and the primary on the right when the buttons are on the bottom right, but I don't like the inconsistency and I'm not sure if this is going to freak users out. Commented Mar 20, 2015 at 22:39
  • 1
    My advice: be consistent internally in your user experience. So, your preference sounds fine to me, as long as you keep that logic throughout. The rule there would be "primary action on the edge, secondary on the inside." And if you put the primary action in the middle (common now on mobile) or even edge-to-edge, secondary action would go below (rather the inverse of the first rule). In a grand sense, the rules are arbitrary, but inside your designed experience, they become the laws of the land. And, as styles change, so do user expectations: pay attention and know when it's time to adapt.
    – Taj Moore
    Commented Apr 17, 2015 at 15:30

For a decade before we had the Internet, there was Windows and there was Macintosh.

The Windows standard was to put OK (or whatever the action button is) on the left. The Macintosh standard was to put OK (or the action button) on the right.

As a result of the split standard web designers ended up being confused about what to do. Many of them had only used on OS and did not realize that the standard was different.

There are a lot of silly arguments about which is "best," none backed by actual data. It's like driving on the left or driving on the right.

Pick one standard and stick to it. If you know that your users are predominantly Mac or predominantly Windows, or if you have the energy to sniff the browser agent and figure it out, you can make a decision that is consistent with your user's expectations.

  • 6
    But the OP was talking about whether to put the Submit button at the lefthand or righthand edge of the window, not whether it should be the leftmost or rightmost of a pair of buttons in the lower right of a dialog.
    – Bevan
    Commented Feb 14, 2012 at 8:37
  • There is plenty of data on this. Looking at the Gutenberg Diagram, it states the CTA buttons need to be on the right. wpmudev.com/blog/call-to-action-research (scroll to Left vs. Right section) Commented Nov 25, 2021 at 1:11

My professional opinion is to have the submit button on the Right in all instances. My reasoning is that it is a continuation action; you're proceeding on to another page / action, 'turning the page' as it were. Actions for moving forward I place on the right, actions for moving backwards I place on the left for LtR reading languages. (With a decent amount of space inbetween the two buttons to reduce accidental clicks).

This will be the same throught the applications for all such actions. Slideshow of images: next slide button on the right, previous button on the left. Next page of products: Next button on the right, previous on the left.

I understand some of the quirks here; that within forms the Tab order would then land on the Cancel (or negative action) before the Confirmation option. Also that in sections where there isn't a negative / reverse option having the only button on the right may be missed, but as has been pointed out in the links in the OP post and this question thread there really isn't a correct answer. Keeping it consistent is important, and because elsewhere in the site / app the continuation options are on the right that's where I keep the Submit / OK etc buttons too.


Here's a small (64 participants), but interesting little survey that was done on this a few years ago: http://measuringuserexperience.com/SubmitCancel/index.htm . Their conclusion is "With the buttons visually separated, putting the action to continue (e.g., OK, Save, Submit, etc) on the right is more likely to match your users' expectations", but what's obviously missing is a breakdown of the habitual OS usage of their participants.


While @Joel is right regarding the historical perspective, I believe there's more logic in OK on the left. The logic is this - the flow of information is top to bottom, left to right (for LTR languages). Because of this, Whether this is Mac or Windows or Linux or whatever, we invariably put the important stuff on the left - this is clearly visible in menus, for example. And we design our software for people who want to do something with it - to OK their dialogues, not to cancel (otherwise - what's the point? :) ). So OK is inherently more important than Cancel, hence it goes on the left.

But this is just philosophy, in practice I don't think it matters, as @Joel mentioned.

Also, I'm a Windows guy :)


Specifically relating to the form part of the question asked, I agree with submit being on the left (input left-aligned that is) for forms as it follows the scanning path from top to bottom.

Typically in a for the workflow is top to bottom - left to right, not so much.

So in a left aligned vertical workflow, why suddenly right align the primary action button? LukeW ( LukeW Web Forms ) says: vertically align with the input fields. This illuminates a path for users and guides them to completion of the form.

But as @Joel says (and we are honored! :) there is also the convention argument - if most people (given the same OS and other factors) put the button on one side, then unless you have a really good reason, and can show that it's really better for your users, don't break convention.

To meet a user's expectation is a great reason to go one way or the other - I'm not sure you need to consider a whole lot deeper than that in many cases - and certainly you're not going to get black and white clarity on whether it's right or wrong.


There is no set spot to align your buttons. It all depends on where the user's line of sight goes. If you have a one column form, your users' eyes are going to finish on the left. If you have a two column form your users' eyes are going to finish on the right.

There's also multi-page and multi-section forms, but the reason behind the alignment is a little different.


There is no right or wrong anser to this one. Regardless of history, what I find works best is just being sensible with visual heirachy for each situation.

If there are only two actions (eg: Save & Cancel), to me it makes most sense to make the 'Save' more prominent as it is (in most cases) the primary action. I would usually put this button on the left, and not use a button at all for 'Cancel', rather a hyperlink offset a sensible distance from the button. Both actions are present, one is emphasised. But you need consistency and should only use this if whatever you are designing has relatively simple submission options across the system.

Similar effects can also be achieved by using a coloured button for 'Save' and a greyed out (but stil clearly clickable) for 'Cancel'. Usually ensuring enough contrast exists (eg: primary button solid BG with white out text, secondary lighter button with dark text) between the two buttons - helps for the colour blind/visually impaired.

Other tricks such such as only activating Save buttons once somehting has been modified and can be saved helps draw attention to it once editing begins (assuming it's visible scroll).


Lets look at the "Law of Closure" to find solution to this question. In Architecture there is a term called Closure to the form to align aesthetics and create punctuation.

So What does the buttons do in a form? It highly closes the form temporarily or permanently. Temporary is a means to continual process, as in a wizard, moving to the next item or page.

There needs a closure to the page which means RHS aligning of buttons are mostly suitably good, since it creates tenacity to the page. Contrarily LHS aligning of buttons may look to keep eye fixation at better levels, but it is less emotionally satisfying on performing the action, thinking in terms of pyschological factor.

I vote for RHS keeping pyschology, aesthetics and design theory rules.


To me this would be the logical order:

<Left Right>

<Previous Next>

<Back Forward>

<Back Done

Go back Continue

Do nothing Do it

Cancel OK

Except OK should be replaced with the actual action such as Save Delete Accept Exit or Send.

When I meet people arguing for putting OK on the left, I always ask them to place Left vs Right, Previous vs Next, and Back vs Forward, and let them argue why they put them in that order, before letting them argue why OK should be on the left.


I think usability specialists make one huge omission when thinking about right/ left placement - they omit to put mousing in the account and reason only over reading patterns: https://cogsci.stackexchange.com/questions/2056/any-research-on-right-hand-left-hand-based-preferences-when-interacting-with-an

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.