I have a situation where a user opens some options that appear in a popup. They can make their changes and then either Save or Cancel, both of which close the box and save/discard the user's changes.

There seem to be different approaches regarding whether the Save button should be enabled if the options haven't changed from their initial state (Or have returned to their original state)


  • Save is always available
  • Save is only enabled when changes have been made

It seems "Smarter" to only allow saving when changes will actually be saved, and the a disabled save button may potentially reassure some users. However, I generally don't like the user being prevented from saving valid data, even if that data hasn't changed.

Is there a best practice way to do this? Or is it simply a matter of using whichever feels most applicable to each situation?

  • I faced a similar problem a while ago. The best solution we chose was to “gray out” the save button so that it would be clear that it exislts but was not enabled due to some condition not having been met. Having it appear suddenly when required felt a bit jarring. Optionally, you could also add a text that reads “No changes have been made” just above the save buttons so that users can have the fact that no saving is required re-enforced. Commented Jun 30, 2019 at 6:19
  • If 'Save' closes the popup, shouldn't it be an 'Ok' button? Commented Jul 1, 2019 at 19:20

5 Answers 5


I'm with you. Disable a save button makes sense if the data to be saved is not valid e.g mandatory field missing, wrong value etc. In this case the invalid / missing fields should be clearly marked with instructions how to fix it. This way it is clear to the user why the save button is disabled.


to offer yet another perspective,

I would advise to not block any user actions that do no possible harm to the user.

  • For all situations when clicking save would cause no harm, leave it enabled. Disabling potentially makes the user think: "I want to click this button, why can't I click this button? What should I do to enable it?" If there is no harm, all these questions get in the way of the task the user wants to achieve. Especially if there are also other (legitimate) cases where the button is disabled (e.g. an invalid field somewhere).
  • For situations where there is possible harm, e.g. updating the 'latest date saved', putting the content on the top of a widely viewed list of content), or when clicking save starts a Submit process, with many potential errors, or when the content is shared, and saving may cause race conditions, then disabling may be in the user's best interest.

The best practice in your case would then depend very much on context and the possible consequences of clicking save. Not all popups with forms and buttons should be treated equally.


Disabling Save button avoids confusion whether user has made any accidental change between consecutive Save clicks. Also, it gives feedback that current state of form us already saved.


I'll pose an answer from a different perspective: Available functionality (Form follows function).

If your form "can' be submitted, then show an 'active' submit button and allow users to save it. Let the form elements reflect the available functionality of your form.

Let the elements reflect how 'smart' you've built this form. There is nothing bad about saving an unchanged form except the server load. Sometimes users may even like the reassurance even if it is unnecessary. However, I strongly believe a state change of form submit is integral to showing either a change has been made, reassuring I have not changed anything or showing me an appropriate exit path.

The reality is that you would have to perform some validating check to enable/disable the submit/save button anyway, and it is then very easy to have your styles follow that ruling. The hard part isn't, "should the button be active", but rather does the functionality exist to accurately enable/disable the submit element? That's what we are showing the user (truth and honesty e.g. transparency).

So let "form follow function". Form following function is quite defensible in most cases.

Mostly it is about the ecosystem. What have I already been taught? Is this consistent with the rest of this ecosystem?

It would be the "where's my safe exit path", "changes have been made and need to be saved", and "I will not break anything" voices that are the most compelling in providing visual form state feedback to users.


Depend on the cases I experienced during work in the software field, this depends:

1- The logical behavior is either HIDE or TAKEOUT the save button in case if you didn't make ANY change even checkbox on and return it back off it will be counted on you as a change. For this reason, most of the systems deal in this manner Recommended!

2- The other option is to keep the save button open all the way, either you did a change or not. And this too depends on either the behavior you want or the technology you are using, for example in Angular if you checked the material design you will notice that when you got a case with Save and Cancel buttons both of them are always active regardless your changes.

*Regarding the smarter option to prevent saving wrong data, I think this is a nice idea but not practical, because you may be filling a whole form and you spent time doing that, and let's say you missed one field or just a checkbox, not fair to do not save it. In case you find a wrong field you can put a red outline for that field to correct it without connecting it to save button.

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.