DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป

DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป is a community of 966,155 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Claire Parker-Jones
Claire Parker-Jones

Posted on • Updated on • Originally published at clairecodes.com

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>
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (32)

Collapse
 
devhead profile image
dev-head

Nice write up on how to! thanks.

As to the why/why-not, let me take a moment and opine on that...

Please, please just don't do this at all, blocking the UX of a browser because you, or more likely your project manager, wants to be clever and pander the the lowest demonimator doesn't mean you need to. all it does is get in the way of what you want the user to do, and that's give you information. I shouldn't need to confirm my email, any more than i should have to confirm my middle name twice.

Collapse
 
bitdweller profile image
Pedro Pimenta

In addition, I use a password manager to store my credentials and I usually copy most of the data, so it actually makes it more prone to errors in this case. There's no way I'm going to make a mistake if I copy it. Same goes for Credit Card number or account number, so many of them you can't paste into...

Collapse
 
philnash profile image
Phil Nash

I also agree with this, most notably around password managers. If a user is trying to practice good password behaviours but it thwarted by a lack of pasting into a field, then it is likely to get them to choose to use an easier to remember password (probably something they've used before) and makes their account vulnerable to take over.

As developers it is our jobs to help our users be secure, not make it harder for them.

Collapse
 
aurelio profile image
Aurelio

Came here to say just that.
If you use a password manager, chances are you don't even know your passwords, so how are you supposed to type them twice? For many websites I am subscribed to I literally never typed my password once, not even in the moment of choosing it.

This is true for most sensitive data, the best option is to have it pre-filled for you via an extension or at least copy paste from another app.

To give a real world example of why disallowing copy paste is inconvenient for the user, just imagine you are on mobile and trying to fill in a form that prevents pasting. You'd have to either split the screen (browser and password manager app) which is always fiddly, or just flip back and forth and copy a password that is probably (and hopefully) not very readable, or manually write it down on a piece of paper and then input it in the form...

How many people would willingly go through this?

Collapse
 
_bigblind profile image
Frederik ๐Ÿ‘จโ€๐Ÿ’ปโžก๏ธ๐ŸŒ Creemers

Amen!

Collapse
 
mordechairoth profile image
mordechairoth

I think it may depend on why the email address is needed. For example on the Chase bank website, when you are trying to send money to another person using their email address, they make you confirm the email address by typing it in twice, and you cannot paste it.
This prevents you from accidentally sending money to the wrong person, and I think this is a reasonable safety measure to take in that situation.

Collapse
 
joelnet profile image
JavaScript Joel

Should you disable the paste function?

Opinion alert: There is a special place in hell for websites that prevent paste.

There's nothing worse then having to manually type a 32 char mixed case password.

Collapse
 
thomasjunkos profile image
Thomas Junkใƒ„ • Edited on

Thank you for all your effort put into this!

But please stop propagating this bad practice.

I have passwords with at least 64 characters and I am not going to enter them on a site whatsoever. If your site forces this ill type behaviour you lost me as a customer.

This is not meant on a personal level. This practice leads to awful security practices.

Collapse
 
peter profile image
Peter Kim Frank

Claire, thank you for the article and for the clear explanation of how this works. That technical rundown is the basis of your article, not the separate question of whether this is a good practice or optimal UX. You in fact raise the question of whether people should do this directly in the post.

The growing consensus in the comments is that it's not a generally-desired behavior, but that doesn't detract from your worthwhile explanation and write-up. Thanks for sharing with the community!

Collapse
 
scotthannen profile image
Scott Hannen • Edited on

Thanks for the article. It's good to know how stuff works. Like everyone else I wish to clarify that the following comments are about the behavior, not the very nice article.

If it was possible to force users to type numbers into a box using the row of keys at the top instead of the keypad, would we do that? That's what preventing paste is. It's an attempt to control how users do something even though the end result will be exactly the same.

If something doesn't let me paste I'll open up the dev tools and set the properties directly in the DOM. The same goes for pop-ups that can only be closed by saying, "No, thanks." No, I won't thank you. I'll delete you.

Collapse
 
dmikester1 profile image
Mike Dodge

"If something doesn't let me paste I'll open up the dev tools and set the properties directly in the DOM."
Never thought about this before! Genius! Thanks for the tip!

Collapse
 
thejoezack profile image
Joe Zack

Great read, but I have to agree with some of the other comments.

I have auto-fill and a password generator, so I rarely need to type an email or password (or credit card, phone number, etc) so it drives me nuts when a service forces me to type something.

Especially when that something is something like Fq7RE4s5Yc@HAdysa2xH

*Edit: dangit, now I have to change my dev.to password ;P

Collapse
 
detunized profile image
Dmitry Yakimenko

How to prevent pasting into input fields

Don't!

Collapse
 
andy profile image
Andy Zhao (he/him)

Thanks for the write up! Think it's great to know how a website might build this feature so maybe we can workaround it with script runner like Greasemonkey. ๐Ÿ™ƒ

Collapse
 
jrtibbetts profile image
Jason R Tibbetts • Edited on

Here's an even better how-to: Don't.

Preventing users from pasting into a password field is a terrible, terrible design. How is copying & pasting any different from using a password manager's auto-fill feature?

Collapse
 
kubukoz profile image
Jakub Kozล‚owski

Can you add a paragraph in the beginning with "don't do it"?

Collapse
 
caseywebb profile image
Casey Webb

Unless you have nothing but contempt for users of password managers, do not do this. Ever. Period.

While I'm at it, don't enforce arbitrary whitelisting/blacklisting of special characters, and if you're going to enforce a max-length make it at least 32 chars.

Collapse
 
qm3ster profile image
Mihail Malo • Edited on

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
}
Collapse
 
davidjfelix profile image
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.

Collapse
 
lampewebdev profile image
Michael "lampe" Lazarski

I believe that the intention your having is good!

Users have week passwords and tend to forget them or use the same password again and again. This is not a good thing.

What I don't understand is why is the typo thing such a big concern to you?

I also believe that instead of saying the user what he should not do, we should say what would be a better option.

Something like: Hey your password looks week do you know that password manager could help you here?

or

just generate a very good password for the user and inform him/her why this password is good.

Collapse
 
jreina profile image
Johnny Reina

I refuse to use a service the moment it prevents me from pasting input.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

Take a look at this:

Settings

Go to your customization settings to nudge your home feed to show content more relevant to your developer experience level. ๐Ÿ›