Skip to content

FREE TOOL

Twitter ID Finder

The Twitter ID Finder is a browser tool that converts an X or Twitter handle into the permanent numeric user ID behind it, and converts a numeric ID back into the current handle. It runs the same live user lookup endpoint our API serves, so the answer is read from X at the moment you ask rather than from a cached list. Handles change and get reclaimed, numeric IDs never do, which is why every durable record should be keyed on the ID.

The key is sent to this site once, forwarded to the API for this single request, and never stored. Every lookup on this page is one read call at $0.0008. New accounts start with $0.50 of credit, which is 625 lookups. Create a key or read the API key guide.

Why store the ID rather than the handle

A handle is a display name with a rename button attached to it. The owner can change it, and once released the old handle can be taken by somebody unrelated. Any table that keys rows on a handle therefore has two silent failure modes: a row that stops resolving because the account renamed, and a row that keeps resolving but now points at a different person. The numeric ID has neither. It is assigned once at account creation and is stable for the life of the account, so it is the value to write into your database and the value to compare on.

The practical pattern is to resolve a handle to an ID once at import time, store the ID as the key and the handle as a refreshable label, then read profiles by ID from then on. The Twitter user API page covers the full profile object both endpoints return, and the followers API page covers walking the follow graph once you have IDs to walk it with.

The same lookup in code

There is no package to install. Both directions are one GET request with one header, so anything that speaks HTTP can run them.

# handle to numeric ID
curl "https://api.twitterapis.com/twitter/user/info?username=naval" \
  -H "Authorization: Bearer YOUR_API_KEY"

# numeric ID back to handle
curl "https://api.twitterapis.com/twitter/user/info_by_id?user_id=745273" \
  -H "Authorization: Bearer YOUR_API_KEY"

Both calls bill at $0.0008 each. The quickstart runs the same request in Python and JavaScript, and the language clients page carries a working client for each language.

Frequently Asked Questions

A Twitter user ID is the permanent numeric identifier X assigns to an account when it is created. It never changes. A handle can be changed by its owner at any time, and an abandoned handle can later be claimed by a different person, so a handle is not a safe primary key. Anything you store for longer than a session should be keyed on the numeric ID, with the handle treated as a display value you refresh on read.

Yes. Switch the tool to ID to handle and paste the numeric ID. That runs the user info by ID endpoint, which resolves a numeric ID into the same full user object, including the current handle. This is the direction you need when an old export gave you IDs and you now want readable names, or when you are checking whether an account renamed itself since you last saw it.

Three reasons account for nearly all of them. The account was suspended or deleted, so there is no user object to return. The handle was changed, and the old handle now belongs to nobody or to somebody else. Or the input was not a handle at all, for example a post URL rather than a profile URL. The tool strips a profile URL down to the handle for you, but a link to an individual post carries a post ID rather than a user ID.

Paste the handle or the full profile URL into the field above and run the lookup. It calls the user info endpoint, which resolves a handle into the full user object, and the numeric id field on that object is the user ID. If you want to do this in code rather than in a browser, the same call is one GET request to /twitter/user/info with a username query parameter and a Bearer key in the header.

Each lookup is one read call, billed at $0.0008 on your own key. A new account starts with $0.50 of credit and no card, which covers 625 lookups before you pay anything. There is no plan minimum and no subscription, so if you run five lookups this month you are billed for five lookups.

No, and mixing them up is a common source of confusing errors. A URL like x.com/naval/status/1759123456789012345 carries a post ID in the status segment, which identifies one post. The user ID identifies the account that wrote it. They are different namespaces, both numeric, and both long enough to look interchangeable. Pass a post ID to a user endpoint and you get an empty result rather than an error that tells you what went wrong.