Signing in over Tor tells the site who you are, not where

The exit address changes, the account name does not, and the site has been building a profile of that account for years. Signing in over Tor removes one signal, your ordinary network location, and leaves the rest of the picture intact. That is still worth something, and it is not anonymity from the service you just authenticated to. The distinction is easy to state and easy to forget under pressure.

What the login itself discloses

A successful login is a deliberate statement that this session belongs to that account. From the service's side, everything after it is attributable, including the pages visited, the messages sent and the times of day the account appears.

Tor changes what the destination can observe about your network path: instead of your address, it sees an exit relay. It does not change what you told the site by authenticating, and it does not make two logins from the same account unrelated.

Links inside the account work the same way. A recovery address, a phone number, a saved payment method or a nickname reused elsewhere all attach to the identity you signed in with, regardless of the route the packets took.

A new circuit is not a new account

Tor Browser offers two different actions that people treat as one. A new circuit for the site changes the relay path used for that destination, and it leaves the browser's private state alone. New Identity is broader: it clears browser state, closes activity and starts fresh, which is a different operation with different consequences.

Neither action asks the far side to forget anything. Cookies already issued, a session token held by the site, or a device fingerprint collected at login still describe the same visitor after the route changes.

So a fresh exit address does not read as a new person to a service that knows the account. It reads as the same account arriving from somewhere else, which is exactly the pattern fraud systems are built to notice. That pattern is not a bug in the site. It is the site doing the job you asked of it by logging in, and the only surprises come from expecting otherwise.

What the exit still sees

The exit relay carries your traffic in the clear unless the destination uses HTTPS, which is why the browser's certificate checks matter more on this path, not less. A malicious exit is a realistic adversary for unencrypted traffic, and a login page is the worst place to meet one.

HTTPS protects the content from the exit and does nothing about the account you chose to authenticate. The two protections cover different observers, and neither substitutes for the other.

Expect the account checks

Services routinely respond to a Tor exit with extra verification: a captcha, an email confirmation or a temporary hold. That is a normal reaction to a shared and previously abused source range, not proof that the session was compromised.

The useful response is to complete the supported check once. Switching circuits repeatedly until a prompt disappears teaches you nothing about the account and may look worse than the original prompt. It also wastes the one thing you were protecting.

If a check cannot be completed, that is information about the service's policy, and the decision to make is whether the account is worth reaching without the tunnel. Both options are legitimate; pretending the obstacle is a bug is not.

Decide which goal you actually have

There are two goals people conflate: protecting the route to a known identity, and keeping separate activities from being joined. Tor serves the first well. The second requires not signing in at all, or signing in only with an identity created for that purpose and never mixed with the first.

Name the goal before choosing the tool. If the account must be used, the honest description of the setup is a private path to a known account, and the privacy claim should be limited to what that actually protects.