How to prevent pasting into input fields

Edit 01/02/19: I was frustrated by yet another web form that wouldn’t let me paste my password into the Confirm Password field, wondered how it was done and decided to write about it. My intention with this post was to remain unbiased about whether you should or should not do this, and to encourage you to make your own decision. However, I also strongly encourage you to read the discussion below this post, as it clearly shows how unwanted and unnecessary this feature is.

Thank you to the Dev community members for all of your comments and feedback and for making this site such a positive part of the internet!

---

In some forms, the “Confirm email address” or “Confirm password” fields don't allow users to paste text into them. The idea is to make users type their email or password twice to help catch any typos they might have made in those important "Email" and "Password" values.

How is this functionality achieved? How can you stop your users from pasting content into a HTML input field?

We can use JavaScript to target an input field’s paste event and change how it works:

<input type="text" id="no-paste" />

<script>
  const pasteBox = document.getElementById("no-paste");
  pasteBox.onpaste = e => {
    e.preventDefault();
    return false;
  };
</script>

This code cancels the default behaviour of the paste event (i.e. pasting the contents of the clipboard into the input element). When the user tries to paste content into the field, using either a keyboard shortcut or context menu, nothing will happen.

Try it out in the CodePen example below:

There are also events for the cut and copy action.

There is good support for the paste event in modern browsers. These events are part of the Clipboard API. The Clipboard API also includes accessing the contents of the clipboard, which has varying levels of support. See the caniuse table for the Clipboard API for more information.

Should you disable the paste function?

Now you know how to change the expected behaviour of the paste event in your webpage, the question is whether you should. The answers to this StackOverflow question about the paste event discourage developers from tampering with default browser behaviour. The posters argue against changing expected browser behaviour because it will confuse users. Additionally, if the user decides to copy and paste data into a form field at the risk of it containing typos, then we should allow them to do this.

Each website is different, so there is no definitive answer. It's a good idea to consider questions like this when building your site in order to provide the best experience for your users.

Comments

[Rohan Maji]

I want to do it to prevent spam comment in my site. Because 99% spam commments are done by copy pasteing. So my question is should I do it or not.

[Jarel C]

Mostly this should be avoided, however I see one good use for this. Verifying an account number on ACH payment forms. You want users to actually verify their account number by typing it in twice instead of just copying an incorrect number from the first field into the second. This reduces the invalid account kick backs from banks that happen several days after payment is made.

[Basavaraj SK]

Hi All.,
Instead of taking document.getElementById, directly adding onpaste/oncopy attribute to html input tag is better like shown below =>:

input type='text' oncopy="return false" onpaste="return false" (ngModel)="name"

[David J. Felix 🔮]

While I totally disagree with the incentive to do something like this, I feel like that opinion might already be fully fleshed-out in other comments.

Alternatively, why not consider the UX of this and explicitly which behavior you're trying to prevent. If you're trying to prevent somebody from mistyping a password or email a second time, why not hook the oncopy event from the box you're trying to confirm. Surely the act of copying is what leads people to duplicate errors, if that's the scenario you're working around.

Despite this being a topic that is going to incite a lot of folks, there are half measures if you really don't believe them. I think you'll find fewer annoyed users at inability to copy than paste and it likely prevents most of the behavior you're aiming to prevent. I'd still urge anyone to use these sparingly. Don't take away people's tools because you disagree with them, find a way to present the correct solution as the obvious one.

[Mike Dodge]

I just had a thought. Would it be possible to whip up a greasemonkey script to disable this feature on all sites? Seems like this should be doable.

[Yana]

Thanks! I think this write-up is extremely useful even (especially) for those against paste-blocking; in fact, I just used the information to reverse-engineer a paste block that was really annoying me. (the site was using BOTH a listener and an onpaste attribute, and I only found one of them on my own).
Did I spend much more time doing that than it would have taken to type in the number (twice)? probably.
Was it worth it? definitely.

[Mihail Malo]

How to fix this "solution"

for (const elm of $$('*')){
  if (elm.onpaste) elm.onpaste = undefined
  const {paste} = getEventListeners(elm)
  if (paste) {
    for (const lis of paste) elm.removeEventListener('paste', lis.listener, lis)
  }
}

I get to use the Chrome-specific $$ because I'm already necessarily using Chrome-specific getEventListeners.

The provided example can be defeated by just this though:

for (const elm of document.querySelectorAll('*')){
  if (elm.onpaste) elm.onpaste = undefined
}

[LudwikJaniuk]

Thanks for the write-up, and you do mention it in the end but: don't actually do this. It's a horrible pain if you have your data in a text file and copy from there.

[Frederik 👨‍💻➡️🌐 Creemers]

It can be useful in online exercises, where typing out the answer is an important part of the exercise.

[Reese Poirier]

Excellent article, love that you included a section on whether or not one should. I think that's something developers often don't ask ourselves enough.