What does X's password reset actually reveal?
Whether the identifier you typed belongs to an account — and it tells the account holder that somebody asked.
X's password reset page accepts an email address, a phone number or a username. One X recognises moves the flow forward; one it does not leaves nowhere to go. That difference is the disclosure.
The phone step gives away more than existence. X's own instructions say the page displays Text a code to my phone ending in [XX] — the last two digits of a number you did not hold — and the code it then sends stays valid for 60 minutes.
The reset route is not a read. X says it will immediately send a message to the account's email address. Run this against somebody else and they have an unrequested reset email before you have learnt anything.
Is there a version of this check that sends nothing?
Yes, and it is the one worth running. X's sign-up form has to answer whether an address is already in use before anybody can register with it.
That answer comes from a single request to an availability endpoint, and our email lookup runs it as one of 71 sources. Three runs on 4 August 2026 against an unregistered address returned {"valid":true,"taken":false} in 229, 230 and 272 milliseconds.
Nothing leaves X's side of that exchange. It is a read of a registration form, in the sense the OWASP testing guide means when it lists registration alongside login and password recovery as the three flows that leak account existence.
The masking in our report is ours. A hit renders the address you supplied in a censored form. Our code writes that, not X — the endpoint returns a boolean and no address at all.
What do the discoverability settings change?
Who can be shown your account after uploading your address or your number, and nothing else.
X documents two switches, and the wording differs by platform. Turning either off also stops X using address book contacts somebody uploaded to suggest your account to them.
| Setting | Wording on desktop | What it governs |
|---|---|---|
| Find me by email | Let people who have your email address find you on X | Whether a contact upload holding your address can surface your account |
| Find me by phone | Let people who have your phone number find you on X | The same for a number. Each account on a shared number carries its own switch |
| Sync address book contacts | Sync address book contacts | Whether your own contacts go to X, on an ongoing basis, from that device |
X also states plainly that neither identifier is displayed on your profile, whichever way the switches are set.
The box is numbered and the number is enough to confirm somebody rents it. Whose name is on the lease is a separate question, and it is not written on the door.
Does a phone number behave like an email address here?
Almost, and the exceptions are the interesting part.
The reset form takes a number, you press Search, and the masked ending comes back. But X documents two cases where the number simply will not work: an account enrolled in login verification cannot reset by text at all, and a number attached to more than one account cannot be used at that step.
So a number that fails is ambiguous in a way an address is not. It may belong to nobody, or to somebody careful, or to somebody with two accounts, and the form gives you no way to tell those three apart.
Our phone module is 8 sources and X is not among them. The X check lives in the email module because the endpoint it reads takes an address.
Why is the handle still the better starting point?
Because it returns a profile and an address returns a boolean.
A handle gives the display name, bio, avatar, account ID, creation date, follower and following counts, post count and verification state — the ground covered in the handle-side guide, which is where to go once you have one.
X is a deliberate absence from the URL-pattern list inside our username module, because x.com answers 200 for every handle, real or not, and a naive probe would report every one as found. The X handle check that does run reads a signed-in session, and reports itself unavailable rather than guessing when that session is not loaded.
Which is the honest ordering. Start from the handle if you have one, and treat the address as the thing that tells you a handle is worth looking for.
What each route returns
Five ways in, and they differ more in what they cost the person you are checking than in what they return.
| Route | What it confirms | What the account holder sees |
|---|---|---|
| Handle on x.com | The whole public profile | Nothing |
| Sign-up availability check | The address is registered | Nothing |
| Reset form, email | An account uses that address | A password reset email |
| Reset form, phone | An account uses that number, plus its last two digits | A code by text, only if you continue past Search |
| Contact upload | Accounts whose holder left discoverability on | Nothing |
Only the first row names a handle. The other four confirm that one exists somewhere behind an identifier you already hold, which is a smaller finding than most services selling this admit.
Read the third column before the second. Three of these routes are silent and the two reset rows are not, and that distinction outlasts every product change X makes to the rest.
What an existence hit says about account age
Nothing at all, and that is worth stating because account age is the most useful fact on the platform.
The creation date sits on the profile, so it arrives with the handle and never with the address. A hit on an availability check is one bit: registered. It carries no date, no handle and no history to compare a claim against.
What the hit is good for is deciding where to look. The same address run across the platforms that answer shows which services are worth searching by handle once a handle turns up.
Read in that order the address is a cheap filter and the handle is the evidence. Read the other way round it is an invitation to assume things a boolean cannot support.
What does the archive hold once the account is gone?
The profile, sometimes, and never the mapping you actually want.
The Wayback Machine crawls public profile pages and posts, so a deleted account is often still readable with its bio and its counts on the day it was captured. Every one of those snapshots is filed under a handle.
Which is the catch. No crawler ever indexed the link between an email address and an X account, because X has never published one, so the archive cannot answer the question the address poses.
Absence proves nothing either way. A missing snapshot means no crawler happened to visit, and an address that still reads as taken means only that X has not released it back to the registration form.
So the archive is a second step rather than a first one. It rewards a handle and has nothing to say to an address, which is the same asymmetry running through everything above.
Closing the route on your own account
Three settings, and one route that no setting closes.
Turn off both discoverability switches and X stops matching your address or your number against uploaded contacts. Remove your uploaded contacts separately: X keeps what you sent until you ask for all of it back.
Password reset protection and two-factor authentication are the second layer, and X's own help page names the first of them as the answer to receiving reset emails you never asked for, which is exactly what the route above produces.
The sign-up form is the one that stays open. What X documents for those switches is contact upload and follow suggestions; a registration form has to say whether an address is already in use, which is a different question with a different answer.
Common questions
Can you find an X account by phone number?
You can confirm one exists. X's password reset form accepts a number, and a number it recognises returns the last two digits of the phone on file before sending a code. It does not name the handle. A number attached to more than one account cannot be used at that step at all.
Does an X password reset send mail to the account holder?
Yes. X's help page says it will immediately send a message to the account's email address, containing a code valid for 60 minutes. So the reset form is an existence check that leaves a trace in somebody else's inbox, which is the reason to prefer the sign-up availability check instead.
What does "Let others find you by your email" do?
It controls whether somebody who already holds your address can be shown your account after uploading their contacts to X. Turning it off also stops X using contacts other people uploaded to suggest your account to them. It does not hide your address, which X never displays on a profile anyway.
How do I stop people finding my X account by email or phone?
Open Privacy and safety, then Discoverability and contacts, and uncheck both options. Then remove your uploaded contacts, because X keeps ones you sent earlier until you ask for all of them back. Neither step affects whether the sign-up form says your address is already in use.
Why can't I use my phone number on X's password reset form?
Because more than one account is attached to it. X states that a number shared across accounts cannot be used at that step, and that reset by text is unavailable to accounts enrolled in login verification. Both are reasons a number can fail without telling you anything about whether it is registered.
How long is an X password reset code valid for?
Sixty minutes, whether it arrives by email or by text, according to X's help page on resetting a lost password. The same page notes that completing a reset logs the account out of every active session, which is a second, louder signal to the account holder that somebody has been in the flow.
Is my email address or phone number shown on my X profile?
No. X states that neither is publicly displayed, even with the settings that let others find you by them switched on. The discoverability switches govern matching against uploaded contact lists, not display, so leaving them on never puts either identifier on the page.
What does a sign-up availability check send to the account holder?
Nothing. It is a single request asking whether an address can still be registered, and the reply is a boolean. Three runs on 4 August 2026 against an unregistered address came back in 229, 230 and 272 milliseconds. No mail is sent, no code is generated and no session is disturbed.
Can two X accounts share the same phone number?
Yes. X documents multiple accounts on one number, each carrying its own setting for whether others can find it that way, and says people will find every account on that number which has the setting enabled. It is also why the number stops working on the password reset form.
