Disabling 1Password X for specific fields/forms (web developer question)

Hi—I'm a web developer and an avid 1Password user. I've found that 1Password X and its icon is showing in every field of some forms quite aggressively. I presume it tries to only do so on fields where it thinks it's in a login form, but it's showing in places it shouldn't. It ends up interfering with things like typeahead inputs and anything with custom keyboard press handlers and just generally gets in the way where it shouldn't.

Could you shed some light on how it's choosing to where to show up, and perhaps more importantly for developers like me, is there a specific per-form or per-input attribute we can use to disable it?

As a concrete example, I'm working on an enterprise web application that has a form for editing accounts, so the word "account" is part of the form id and there are username fields and whatnot. This is probably what is triggering 1Password X to insert itself. Unfortunately, 1Password is not actually useful in this context of managing the several thousand accounts of other people in this application and makes a nuisance of itself. :)

Besides having per-form and per-input blacklist attributes, it would be super useful to be able to mark any html with an attribute (e.g. to disable 1Password on child elements and only whitelist specific input fields with a similar attribute (e.g. ) to indicate where it's safe to use. This would give tighter control to app developers who are dealing with issues like this without affecting normal operation of the plugin.

Keep up the great work!

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided



  • pbhoganpbhogan Junior Member

    Hah, I should have known better than to put html in a form. My examples were (excluding the angle brackets):
    body allow-1password="no"
    input name="username" allow-1password="yes"

  • dtearedteare Agile Founder

    Team Member

    This is a great question, @pbhogan. You're right, 1Password is analyzing the page looking for interesting things. Login, registration, and credit card forms are things we're very interested in and decorate them. While things like search fields we want to avoid like the plague.

    Most likely it's exactly as you say: you have the word account in your form and 1Password thinks it's a registration form and jumps in to help. But given that we used machine learning to create the form analyzer, it's not immediately apparent that this is the case. 🙂

    At this moment there is no mechanism to control form categorization like you described. This is something we will likely add in a future update as developers like yourself should be given the tools you need. Pinging @mitch as this is a topic near and dear to his heart.

    Thanks for bringing this up!


  • I came here with the same question / concern.

    Have you considered giving the user an option in the UI to "not suggest for fields like this"....or the opposite, maybe right-click and tell 1Password to suggest? That would give you additional data points for your ML algorithm, and, depending on how your algorithm works, it could allow us developers canto pre-train the system on our UIs before releasing them into to the masses of 1Password users!

  • AGAlumBAGAlumB 1Password Alumni

    It's a cool idea. Perhaps we'll be able to do something like that down the road. Thanks for the suggestion! :)

  • Same here. I'm tired of having to lock 1Password X everytime I input the user search form in HacknPlan.com.

  • BenBen AWS Team

    Team Member

    Sorry for the inconvenience @LagPick. Thanks for sharing your experience with us. Hopefully this is something we can address.


  • Hello guys,

    I have the same problem.

    I'm a web UI developer, and 1Password User, and 1Password places its icon in fields I'd really rather not have icons in.

    1Password get's particularly exited by a field label/id containing 'mobile number'.

    As my webapp uses the label often, I get the icon scattered randomly throughout my application.

    This looks darn ugly, and is very irritating from a UX perspective.

    I'm sure I could personally disable these icons for my browser, but 1Password is popular, and my concern is for the UX of my user base.

    Is there no standard HTML5 attribute that I can add to my inputs to tell ALL password managers to relax and stop offering to help.

    If not, maybe some 1Password specific tag that will do the trick.

    Any assistance will be most welcome.



  • AGAlumBAGAlumB 1Password Alumni
    edited November 2019

    @mee: If you'd like to provide more details so we can actually take a look at it and see if there's something we can do to help with your specific case, please email us at [email protected] so we can take a look. :)

  • Hello,
    For example, I'm using Asana, and in the input for Assing task, is always 1password suggesting an password. How could avoid it?

    You can see it here:

  • kaitlynkaitlyn

    Team Member

    Thanks for the report, @davidperezgar! We fixed this issue fairly recently, but it seems to have made its way back. I've passed the report along to our developers so they can take a closer look. In the meantime, you're welcome to try the 1Password X beta, where we'd added the ability to hide the inline menu on a specific page. If you're needing to assign a bunch of tasks at once, that would come in handy. Let me know which browser you use if you're interested in the beta, and I'll send you over the download link.

    ref: dev/core/core#481

  • zindlerbzindlerb
    edited February 2020

    One workaround I have found is to replace your input tags with textarea tags. The 1password extension seems to ignore textarea tags. Not a great workaround but if your application is more of an application than a website like asana it might be a good solution.

    In the long run hopefully 1password will publish a class that can be applied to elements to explicitly opt out of their input helper.

  • BenBen AWS Team

    Team Member

    I think one concern with that approach is that there are (perhaps surprisingly) still organizations out there that are anti-password manager. I would be afraid some might use such a feature to try and prevent their users from using password managers at all, rather than trying to create better UX.

    An open letter to banks

    That isn't to say we won't do it, but there are some considerations.


  • edited May 2020

    Hi, I hope this doesn't help the banks too much and doesn't hurt people with disabilities, but I was able to work around the issue by setting my label like this: "Invite project members by name or e[special character here]mail" using an invisible comma special character:

    It would be better for 1Password to support an attribute to opt out. They can then choose to ignore it for specific banks.

  • kaitlynkaitlyn

    Team Member

    Thanks for your input on this, @anthonysapien!

  • This is certainly very frustrating as a developer... but perhaps I'm just missing something obvious here? I've made a popup that asks an admin user of my app to enter the email address of a new user that they'd like to add... clearly this would not be in the admin user's 1Password account, but despite me turning autocomplete OFF for this form, 1Password is still popping up for this field.

    Is there an official way to stop it?

    Here's a screenshot:

    Thank you!

  • ag_yaronag_yaron 1Password Alumni

    Hey @jgrinsted

    We're working on a feature right now that will respect autocomplete=off when there's no password field present. It should be released in the next beta update or so, and it should address the issue you're showing here. Hopefully it will be released soon :)

  • This is an issue for me as well in Robohead. When I try to add reviewers the 1password sign-in blocks the dropdown list so I can't see who I'm choosing and rolling over it will cause the drop down to collapse. See link below for screenshot (the textbox in this comment form is on top of the insert image menu so you can't choose an image just FYI)


  • ag_michaelcag_michaelc

    Team Member

    Hey @SomethingBlue42. If you right-click in that field and choose the "Inspect" option, does that field make use of autocomplete="off"?

  • Is it possible to get 1Password to ignore inputs with some unique attribute in addition to autocomplete="off"? Chrome ignores autocomplete="off" and the workaround is to use an invalid value like autocomplete="foo"... This workaround works somewhat reliably for us, but it also makes it impossible to disable the input for 1Password.

    Relevant Chrome bug (feel free to bug them about it too, they shouldn't ignore spec!):

    Related StackOverflow question:

  • Just echoing what @awesomerobot said here. As a user of Discourse, it’s really annoying to have 1Password pop up and take precedence over one of the fields where I’m trying to add users to a message. 1Password seems to think it’s a username field. A simple “Esc” does not really work for me in this case.

    I’m using 1Password 7.7 beta on my Mac, in Safari.

  • ag_yaronag_yaron 1Password Alumni
    edited August 2020

    Hey @awesomerobot ,
    thanks for the additional information and details.

    This is a problematic issue since a lot of websites are abusing the "autocomplete=off" attribute in actual login forms to try and prevent autofilling, because for some reason they think it is safer if the user types their credentials manually. This has been so horribly abused, that not only did we started to ignore it, but browsers built-in password managers started to ignore it as well.

    If we do add a special variable that would allow developers to force 1Password to ignore an input field, the most likely scenarios will be:
    - We will break common web standards by creating our own new standard.
    - This will work great for a few years, until most websites realize this and start abusing our special attribute/variable as well and add it where they shouldn't.

    The solution for us here is to keep improving 1Password's brain and its machine learning to better identify web pages, forms and fields, in a way that it will figure out if 1Password should show up in it or not correctly. Of course - this is easier said than done, but we are getting there slowly. Right now, our addon of respecting the "autocomplete=off" attribute sounds simple but it entailed a lot of smart logic behind it, so 1Password will know to ignore that attribute if it is a login page/form/input field, but will respect it in most other places.

    @galligan Does the field where you are adding users to a message contains the "autocomplete=off" attribute?

  • @ag_yaron Sam here from Discourse. I am also a paying 1 password user. This issue has triggered me to completely disable "show autofill on focus".

    I think it is laudable that you want to improve the brains of 1password but as an end user I am absolutely helpless. When 1password makes a bad choice I can not right click and tell 1password "hey, you made a bad choice here, learn now!". The learning here is very stunted and relies on way too much luck. My feedback should matter, especially when it comes to how I, as an end user use the product.

    Regarding autocomplete off, I get the conundrum. But sadly, Discourse and many many many other platforms take the lesser evil of being broken on 1password over being broken in chrome.

    I also think that autocomplete="unknown_thing" is reasonable to default to "not a password" as a workaround to how the chrome team have decided to disrespect users and ignore it.

  • ag_yaronag_yaron 1Password Alumni

    Hey @samsaffron,

    Firstly, I apologize if it sounded like we don't care for your input, because we do. A lot. And we appreciate everyone here for bringing this up! It is very important feedback for us.

    Secondly, can you please tell me how to replicate the issue on Discourse? I'd like to test things there and see if I can find more relevant information I can forward to our developers so they can handle it better.

    And thirdly, you can tell 1Password X to hide itself on a certain page for the duration of your browser session by clicking the "Suggestions" section when the autofill menu shows up in a field, and selecting "Hide on this page". Eventually, this feature will be more permanent than the current browser session, giving users the ability to teach their 1Password where it shouldn't show up, while we also do our part here and keep improving 1Password 24/7.

    Keep me posted about the steps to reproduce.

  • edited August 2020

    Thanks heaps @ag_yaron

    We have a some more details here:


    I would be more than happy to hook you up with a free trial of Discourse so you can replicate the issue, you need moderator access to be able to trigger the dialog in the OP. If you would like us to do so shoot off an email to team at discourse.org.

    Per session stickiness is sadly not going to work for me, I really need a more permanent solution for my regular use. I would be more than delighted to make any of our dialogs work better with 1password if you have any suggestions bearing in mind we can not afford to regress any of our Google Chrome workarounds.

  • ag_yaronag_yaron 1Password Alumni

    Thanks for the additional info, @samsaffron .

    I've asked one of our developers to take a look at this discussion and see what he thinks.
    In the meantime, it would really help if you collect some details from that field for us, in your Chrome browser:

    1. Right click the 1Password extension icon on the top right corner of your browser and select "Manage Extensions".
    2. Turn on the "Developer Mode" toggle on the top right side of the page.
    3. In the center of the page where you see the extension's details, click the "Background Page" link.
    4. A new window will open. Select the "Console" tab at its top, then click the bottom part of the console so you can write in it.
    5. Type in the following and hit Enter afterwards: localStorage.setItem(“devtools”, “Y”)
    6. Close Chrome completely, then relaunch it and unlock 1Password X. Now, when you right click the 1Password X icon on the top right corner, you should see a new menu option called "Developer Tools" and use it to collect page details.
    7. Get to the page where 1Password shows up in that usernames search field and collect the page details. Save it in a json or txt file and send it over to [email protected] alongside a link to this forum discussion so we can connect the dots faster.

    Once we have the collected page details we will be able to determine the best way to tackle this issue - whether by a custom fix for your specific website or by adjusting some general behavior in 1Password's brain that will affect your website and others as well.

  • ag_jarekag_jarek

    Team Member

    Hi everyone! Jarek from the extensions team here, I'm sorry this is causing issues around the web.

    I completely understand the frustration in regard to the fact that autofill heuristics tend to side-step the autocomplete attribute value, but unfortunately given the requirement that such heuristics work across as much of the web as possible the fix is not as easy as simply using the value of the attribute and believing it verbatim. Speaking from my experience working on autofill here, there are a large number of sites that use the autocomplete attribute incorrectly on fields that we definitely need to be suggesting autofill in (banks are especially guilty of this, but it goes beyond that as well). Believing the value of the attribute in these cases would lead to a degraded experience for large numbers of people across the web.

    We shipped improved support for autocomplete=off on fields to our beta channel of 1Password X last month. In particular, we will now hide the autofill menu by default on fields that are autocomplete=off, unless:

    • The field appears to be a credit-card related field
    • The form in question has at least one field that appears to be a password and at least one field that appears to be a username
    • The form in question appears to be a change-password form

    In our testing this has made a big difference in making 1Password X less distracting around the web, and we hope other people enjoy it just as much as we do!

    Unfortunately it appears that due to the Chrome bug referenced above it's not possible to use autocomplete=off in some cases. We are talking internally about expanding this feature to also hide autofill options by default in fields with non-standard autocomplete attribute values (like discourse as previously mentioned). If that would be helpful to you, please comment and let us know!

    I would be more than happy to hook you up with a free trial of Discourse so you can replicate the issue, you need moderator access to be able to trigger the dialog in the OP. If you would like us to do so shoot off an email to team at discourse.org.

    @samsaffron that would be awesome, thank you so much for the offer! I'll get an email sent here shortly.

  • Feature request: the ability to right-click the 1Password icon in a field and to disable it for that particular field/website. Much like ABP for example lets you customise how certain domains are treated.

    Sometimes the icon is just misplaced and I would like direct control over that as an end-user.

  • ag_anaag_ana 1Password Alumni


    the ability to right-click the 1Password icon in a field and to disable it for that particular field/website. Much like ABP for example lets you customise how certain domains are treated.

    So you would like to disable 1Password for a specific field, or for a specific domain?

  • I believe for a specific field would be the most useful.

  • ag_anaag_ana 1Password Alumni

    Thank you for the confirmation @jorijnsmit :+1:

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file