On March 31, 2026, Google announced that users can now change their Gmail username for the first time. A feature millions of people had been waiting for. Sundar Pichai shared the news publicly, and the response was overwhelmingly positive.
But while everyone was celebrating, I was asking a different question.
I raised my first flag: when you change your Gmail username, does mail sent to the old address still reach you? Years of institutions only know you by that old email, banks, universities, services you signed up for years ago and forgot about. The question sounds simple until you realize you can't notify all of them.
My second flag is where it got serious.
For most people, a Gmail address is not just an inbox. It is their identity across the internet. Every time someone tapped "Sign in with Google" instead of creating a password, on Spotify, Canva, Notion, Airbnb, hundreds of other platforms, that Gmail address became the key those platforms used to recognize them. Years of account history, saved data, purchases, preferences, all tied to that one address.
So what happens to all of that when the address changes?
Those platforms are not inside Google's ecosystem. They built their own databases. They stored your identity their own way. Google can update its own systems instantly, but it cannot reach into thousands of independent platforms and update their records at the same time.
That gap is the problem.
The Explanation
Here is what happens to a user after changing their Gmail username. They come back weeks later and tap "Sign in with Google." Google authenticates them successfully and their account is fine. But when Google passes their identity to that platform, it sends the new email address. The platform looks it up. Finds nothing. As far as that system is concerned, this person has never existed.
No warning. No explanation. A duplicate empty account gets created. In the worst case, they are locked out entirely, losing years of data, history, and access without understanding why.
Why does this happen to some platforms and not others? It comes down to a decision made long before you ever changed your username.
When a platform integrates "Sign in with Google," it has to decide how it will identify returning users. Many platforms took the simpler path: they stored your email address as your identifier. It was easier to build, easier to read, easier to manage. And for years it worked perfectly because Gmail addresses never changed.
Until now.
The right way to do it is to use something Google calls a Subject ID, a permanent internal identifier tied to your Google account. It never changes. Regardless of what happens to your email address, your Subject ID stays the same forever. Platforms built this way are completely safe. A username change is invisible to them.
Google Confirmation
I raised both flags publicly under Sundar Pichai's announcement. The first on April 1st, the second on April 2nd. That same day, Google's developer team published an official article titled "Supporting Google Account username change in your app," confirming exactly what I had identified: platforms using email address as the primary identifier may fail to recognize users after a username change, potentially resulting in duplicate accounts or complete loss of access to existing data.
The first flag, about email delivery, Google's feature design had already solved. The old address stays active as an alias, both addresses point to the same inbox, nothing gets lost.
The second one, the identity risk across third-party platforms, Google confirmed as a real and ongoing problem.
Supporting Google Account username change in your app →
What You Should Do
If you're considering changing your Gmail username, don't do it without taking these steps first.
Before switching, open your Google Account, go to Security, and find "Your connections to third-party apps & services." This gives you the full list of every platform tied to your Google identity. Go through it. For anything important such as banking, productivity tools, subscriptions, anything with years of history behind it, log in and confirm your access now, while your current address is still active.
After switching, go back to those same platforms one by one and manually update your email in their account settings, wherever that option exists. Don't wait for a failed sign-in to find out which ones were vulnerable.
For platforms with no manual update option, reach out to their support before you need to. Keep a record, a screenshot, an email, anything that shows the account was yours.
The feature is available today. The risk is real today. A few hours of preparation now is the difference between a smooth transition and losing years of access you can't easily get back.
Closing Thought
Google built a genuinely useful feature. Giving people the option to change an address they've outgrown, tied to an old name, an old version of themselves. This is a good thing to add.
But identity-level features carry a different kind of responsibility than most. For years, thousands of platforms built their systems around the assumption that a Gmail address doesn't change, without ever really questioning it. That assumption doesn't hold anymore, and most of those platforms don't know it yet. Most users don't either.
Google told developers. But developers aren't the ones clicking "change username" on a random Tuesday because they finally can.
That's really the gap here. The people actually taking the risk are the ones least likely to know it exists.
Visual references in this article are adapted from Google Developers blog, Source: developers.googleblog.com
Top comments (1)
Good catch and good follow-through — raising it publicly and getting the developer-team confirmation the same day is more diligence than most security writeups get. The email-vs-Subject-ID framing is exactly right, and worth saying out loud: the OIDC spec has said this for a decade.
subis the only stable identifier;emailis explicitly not guaranteed stable. The feature just turned a spec footnote into a mass-market incident.One nuance for anyone here who builds integrations:
subis audience-scoped. The same Google account presents a different sub to each OAuth client, so a platform can't merge identities across its own multiple apps by joining on sub alone — and a team that "did it right" but spans several client IDs still needs email as an internal join key. That's one of the quiet reasons email-keying got so entrenched even among teams who knew better.The nastier operational edge is the write path, not the front door. Even where sign-in is keyed on sub, plenty of systems cache the email into other stores — billing profiles, notification services, CRM records — and nothing in the OAuth flow pushes the change downstream. The user signs in fine, feels relieved, and the billing system keeps mailing the old alias for months. Email-as-identifier fails loudly at login; email-as-cached-attribute fails silently in the back office.
Did Google's article say anything about the migration path? Going from email-keyed to sub-keyed has a backfill problem: you can only capture the sub at next login, and matching that login to the existing account usually means joining on email — the very field that just changed. Curious whether they gave platforms a workable sequence or just the warning.