TDATA, Session et JSON : le choix du format que cette étagère ne propose pas

The standard advice on this topic is to decide which format suits your setup and then shop for it. Desktop client means TDATA, Python means a session file, custom tooling means JSON. It is tidy, it is repeated everywhere, and it does not describe what is actually for sale.

What the listings actually say

Counted across every live Telegram listing on this site, by what the title names:

• Just under half the shelf, and about two thirds of the listings that name a format at all, name all three in the same title.
• A smaller group, roughly one listing in seven, names TDATA alone.
• Listings selling a session file alone: none. Not a small number. Zero.
• Listings selling a JSON alone: none, on the same count.
• The remaining quarter of the shelf names no format in the title at all.

The search side agrees. "telegram tdata session json" is itself a search suggestion, and so are "buy telegram session json" and "buy telegram tdata session". People type the names as a set because they are sold as a set. Search "telegram json file" on its own and the suggestions wander off into unrelated territory within four entries, which is what no demand looks like.

Our own catalogue taxonomy tells the same story from a third direction. Of the tags used across this site, exactly one names a delivery format, and it is TDATA. There has never been a session tag or a JSON tag, because there has never been anything to attach one to.

Why they travel together

Because they are not three products. They are one authorisation, packaged for different readers.

A seller who has a working account can export the desktop client's data directory and can also generate a library session against the same authorisation, and the JSON is the small text file recording which API identity that session was created under. Producing all three costs almost nothing once the first exists. Producing only the middle one and withholding the others would be extra work for no gain, which is why nobody does it.

The practical consequence is the useful bit: you are not choosing, so stop treating it as a decision. Check that what arrives includes the one your tooling reads, and expect the others in the same archive whether you wanted them or not. The sibling guide on this blog covers what each artefact is on disk and what can be inspected in it, and that is the more useful question once you have stopped shopping for a format.

Format does not price the listing

One more thing the "read the format before you read the price" advice gets backwards. Comparing groups against the middle of this shelf, the listings naming all three formats sit slightly below the median, the TDATA-only group sits essentially at it, and the listings naming no format at all are the dearest of the three.

The TDATA label itself prices at the median almost exactly. It is the default, not an upgrade. Whatever is moving prices on this shelf, it is not the delivery format, and sorting by it will not find you a better account.

Deploying to a second machine, in the order that works

This is where the old version of this page was not merely unhelpful but wrong. It ended by telling you to terminate old sessions and set a new password "the moment the account logs in successfully". Half of that instruction is impossible at that moment.

Telegram refuses to let a session log out any other session until it has itself been signed in for 24 hours. The refusal covers ending one device, ending all other devices, and even setting the session expiry, so there is no indirect route. Setting the two-step password has no such restriction and works immediately.

So the working sequence on an imported account is:

1. Import onto a clean, dedicated environment, one account per machine or per profile, before anything else touches it.
2. Record the device list immediately. Count, device types, regions, last-active times. You cannot act on it yet, but this is the only moment the arrival state exists, and on most listings here the warranty window is measured in hours.
3. Set your own two-step password and your own recovery address now. This works in the first minute and it stops any further session being added with the phone number.
4. Come back after 24 hours and clear the sessions you do not recognise, from that same machine.

The 24-hour gap, which is the real exposure in a bulk deploy

Deploying one account, the gap is an inconvenience. Deploying thirty, it is the thing to plan around, because the files you were sent can be copied and you have no way to know they were not.

During that first day the previous holder is in a strictly better position than you are: their session is old, so it can terminate yours, while yours is new, so it cannot terminate theirs. Nothing in any of these file formats prevents a second copy from being loaded elsewhere, and the lock that protects an ordinary user from a stolen code is, in a handover, protecting the person you bought from.

Two things follow. Stage imports so that the 24-hour marks do not all land while nobody is watching, and treat the password change in step three as the step that actually does something on day one, rather than as the formality it is usually described as. It does not evict anyone. It stops the roster growing.

Handling the files themselves

Every one of these artefacts is a live authorisation rather than a credential you could change. That is why the ordinary rules about passwords apply to them more strictly, not less.

• Do not move them over unencrypted channels and do not leave them sitting in a shared cloud folder after the import is done.
• Delete your copies once the import is confirmed working, rather than accumulating duplicates across machines.
• If a password file ships alongside the folder, treat it as the seller's password, not yours, until you have replaced it.
• Do not plan a phone-based workflow around these files. Neither format imports into a mobile client.

On network setup, one claim that used to sit here has been removed because it cannot be checked: that assigning a proxy per account stops Telegram associating unrelated accounts. No first-party source says that and none is reachable, so it is not stated here. What is checkable is that Telegram derives the country and region it shows against a session from the IP that session connected from, so a fixed connection is what makes that column stable and readable.

If you go looking on our proxy shelf, read the titles carefully rather than the category name. It currently holds 83 live listings, of which the residential proxies subcategory accounts for 20, and a little under half of the whole category are consumer VPN subscriptions rather than proxies at all. It is a shelf where the category label and the product are not the same thing.

What to confirm before you buy

• That the archive includes the artefact your tooling reads. Not which format the listing is "in", since most name several.
• Whether a password is included, and whether the seller states it is theirs. An account you cannot get into is worth nothing regardless of format.
• How long the warranty window is, because the checks you can complete inside it are the inventory and the password change, and not the session clearing.
• That you have somewhere clean to import it, prepared in advance.

Several suppliers on this site list accounts packaged this way, and it is worth comparing what a listing actually ships against what its description implies, since those diverge more often than they should. For a narrower focus on format and geo breakdowns specifically, tgaccounts.net is another storefront that documents tData, session, and JSON delivery options alongside tenure notes, separate from general marketplace listings.