Telegram Session File vs TDATA: 3 Formats Compared

Buy a Telegram account and you will be asked which format you want it in, usually as three options with no explanation: session file, TDATA, or number plus code. The choice looks administrative and is not. Two of those three hand over a live credential that works immediately and can be copied without limit, and the third does not. This guide explains what each format actually contains, measured rather than described, along with how to convert between them, what breaks when you do, and how to take custody of an account without inheriting somebody else's access to it. The session file section is based on a file created and opened for this article, not on recollection.

The Three Ways an Account Is Handed Over

Every Telegram account transfer uses one of three formats, and the differences are about credentials rather than convenience.

Session File

A single file holding an authorisation key produced when the account logged in. Point a library at it and you are that account, immediately, with no code and no phone. It is the format automation uses because it needs nothing interactive.

It is also the format with the least ceremony attached to it, which is part of why it gets chosen without thought. A file arrives, a script points at it, work begins, and nobody involved has stopped to consider that the same file could be sitting in three other places.

TDATA

The local data folder that Telegram Desktop keeps for a logged in account. Copy it into another installation and that installation opens already signed in. It is the format for someone who wants to use the account like a person rather than through a script.

Because it is a folder rather than a file, it also travels less tidily. People compress it, send the archive through a chat, and leave the archive there, which means the account is now sitting in a message history belonging to whichever platform they used.

Number Plus Code

No file at all. You get the phone number, the seller relays the login code as it arrives, and you sign in yourself on your own device. It is the slowest of the three and the only one where the credential is created by you.

That last sentence is the whole of the security difference between the three, and it is worth reading twice before choosing on convenience.

What a Session File Actually Is

Most writing on this subject describes the session file as somewhere the login is stored. That is true and useless. Here is what it is, from opening one.

It Is a SQLite Database

A session file created by Telethon, the most widely used Python library for Telegram, is an ordinary SQLite 3 database. The first sixteen bytes of the file say so in plain text. An empty one, freshly created with no account attached, is 28,672 bytes. Any SQLite tool opens it.

This matters because it removes the mystery. The file is not encrypted, not obfuscated, and not proprietary. Anyone who has it can read everything in it with software they already have, and that fact should shape how you handle it.

The practical use of knowing this is diagnostic. When a session behaves strangely you can open it and look rather than guess: whether it has an authorisation at all, whether the entity cache is enormous, whether the schema version matches the library you are running. Three of the four common failures in this area are visible from the file itself.

The Tables Inside

A current session file has five tables. sessions holds the connection details and the authorisation key. entities caches people and chats the account has encountered. sent_files caches uploads so repeated sends do not re-upload. update_state tracks the account's position in the update stream. version holds a schema number, which is 8 in the current library release.

Nothing in that list is secret and nothing is complicated, which is worth saying because the subject is usually discussed as though the file were an opaque artefact. It is five tables and one of them matters.

The Column That Is the Account

Inside sessions the columns are the data centre identifier, the server address and port, the authorisation key, and two fields for takeout and temporary keys. The authorisation key is the account. It is not a password, it is the result of having logged in, and it does not expire on a schedule the way a password does.

So there is no meaningful sense in which you can share a session file but not the account. They are the same object. A copy of the file is a copy of the access, and there is no counter anywhere limiting how many copies exist.

The takeout and temporary key columns are the ones nobody asks about. They exist for data export and for short lived connections, and neither changes the basic picture: the file holds credentials, in the plural, and possession is the whole of the access control.

What Else Is In There

The authorisation key is the part everybody knows about. The rest of the file is the part that matters when an account changes hands.

The Entity Cache

The entities table stores an identifier, an access hash, a username, a phone number, a name and a date for the people and chats the account has dealt with. It is there for performance, so the library does not have to resolve the same username repeatedly.

The consequence is that a used session file carries a partial contact list of whoever used it before. If you receive one, you are receiving that. If you hand one over, you are handing that over. Neither party usually thinks about it, and it is the single most overlooked thing in this whole subject.

The cache also grows. An account used for outreach across months accumulates entries for everyone it contacted, which is why an old working session file can be considerably larger than a fresh one and why size alone tells you roughly how much the account has done.

The File Cache

sent_files maps a hash and size to an already uploaded file so the same media is not sent twice. It is harmless and it is also a record of what has been sent from that account, in the sense that the entries exist at all.

It is the one table you can clear without consequence if you want a smaller file, since the worst outcome is that a re-sent file uploads again. Do not treat that as general permission to edit the database, because the other tables are not so forgiving.

Update State

update_state keeps the account's position in Telegram's update stream. Delete it and the account re-syncs; it is the least sensitive thing in the file and the most likely to cause confusing behaviour if two copies of the same session are used at once, because both are trying to hold a position in the same stream.

If you are moving an account between machines deliberately, expect a short period of catching up rather than instant continuity. That is the update position resynchronising and it is normal, not a sign that the transfer failed.

Why Two Copies Fight

Running the same session file from two places simultaneously is the most common self-inflicted problem in this area. Both connections authenticate correctly, both are the same account, and they interfere: updates arrive at one and not the other, operations fail unpredictably, and in the worst case Telegram treats the pattern as suspicious, which our guide on avoiding account bans covers from the other direction. One session, one running process, always.

The reason this is worth stating plainly is that the symptom does not look like the cause. Nothing reports a conflict. You get intermittent failures, missing messages and behaviour that changes between runs, and the natural response is to blame the network or the library rather than to look for a second process nobody remembered starting.

What a Session File Is Not

Three assumptions get made about these files that are worth removing before you rely on any of them.

It Is Not Encrypted

Telethon does not encrypt the session file by default. Anyone with the file has the key in plain form. Storing them in a shared folder, a synchronised cloud drive, or a code repository is exactly as safe as storing the passwords in the same place, which is to say not at all.

There is a straightforward habit that removes most of the risk: keep session files in one place, on one machine, and treat that folder the way you would treat a wallet file. The people who lose accounts to this almost never lose them dramatically; they lose them to a synchronisation client doing exactly what it was installed to do.

It Is Not Revoked by Changing the Password

Two-step verification protects new logins. It does not invalidate an authorisation that already exists, so changing that password does not evict somebody holding a copy of your session. The action that does is terminating the session from Telegram's own active sessions list, and that is the step people skip.

This catches experienced people, because the mental model from every other service is that changing the password logs everyone out. Telegram separates the two deliberately, and the separation is useful once you know about it and expensive until you do.

It Is Not Portable Between Everything

A Telethon session is a Telethon session. Other libraries use their own formats, and the string form some tools export is a different encoding again. Conversion is possible and it is a conversion, not a copy, which is where most of the practical failures in this subject come from.

When a file will not load, check what produced it before assuming it is corrupt. A session written by a different library, or a string export pasted into a file, will fail in ways that look like damage and are actually a format mismatch.

TDATA: The Desktop Format

TDATA is what Telegram Desktop keeps on disk for an account that is signed in. It sits beside the application's own data and it is a folder rather than a single file.

What It Is For

Its job is to let the desktop client reopen without asking you to log in again. Copy the folder into a fresh installation on another machine and that installation opens as the account, which is the property that makes it a transfer format even though it was never designed as one.

It is also why TDATA feels safer to non technical users and is not. Nothing about it being a folder inside an application makes it less of a credential; it simply looks more like configuration and less like a key.

How It Differs From a Session File

The session file exists to be used by code with no interface. TDATA exists to be used by a person with one. That is the practical difference and it drives the choice: if the account is going into a script, the session file saves you a conversion step, and if a human is going to read messages and reply, TDATA saves you the same step in the other direction.

The internal layout of TDATA is not documented by Telegram and this guide does not guess at it. What can be said without guessing is that it carries the same class of secret as the session file, which is a live authorisation, and everything below about custody applies to it identically. Where the account connects from is a separate question with its own answers, covered in the proxy guide.

The Local Passcode

Telegram Desktop can lock its local data with a passcode. When that is set, the folder is not usable on its own, which is genuinely useful and also the reason a transferred TDATA sometimes refuses to open on the new machine: it was locked and the passcode did not come with it. If you are buying, ask before you receive rather than after.

If you use the desktop client seriously, setting the local passcode is worth the small daily friction. It converts the folder from a portable credential into something that needs a second factor you hold, which is the only mechanism in this whole area that limits what a copy is worth.

Version Sensitivity

TDATA belongs to the desktop client that wrote it, and moving a folder between substantially different client versions is more fragile than moving a session file between library versions. Keeping the receiving installation current, and not mixing portable and installed versions, avoids most of it.

Keep a note of which client version wrote a folder if you are storing them for any length of time. Six months later, with nothing recorded, a folder that will not open is indistinguishable from a folder that is broken.

Number Plus Code: The Format With No File

The third option is the one people skip because it takes longer, and it is the only one that gives you an account nobody else has a working key to.

How It Works

You get the phone number. You start a login on your own device or in your own script. Telegram sends the code to the number, the seller relays it to you, and you complete the login. The authorisation that results was created by you and did not exist before.

It is worth doing the login somewhere you control rather than in a hurry on a shared machine, because the authorisation you create is the one you are going to depend on. The five minutes spent here is the only point in the whole process where you get to decide where the key comes from.

Why It Is Different in Kind

With the other two formats you receive a copy of a credential and have no way to know how many other copies exist. Here you create the credential. The seller still had access before you, and can still receive future codes if they hold the number, but the specific authorisation your software uses is yours alone from the start.

That distinction is worth a delay of a few minutes on anything you intend to rely on. For a disposable account it is overhead; for one carrying real work it is the difference between owning something and borrowing it.

There is a second benefit that is easy to miss: nothing arrives with a history. No cached contacts from somebody else's campaigns, no leftover state, no file that was sitting in a shared folder for a month before it reached you. You get an account and a key you made.

The Catch

Whoever controls the number can request a code later, and a code is a login. This is why number plus code is better than the file formats without being perfect: it fixes the copied-credential problem and does not fix the underlying ownership problem, which nothing in this list does.

The mitigation is the same one that applies everywhere here, which is to set your own two-step verification immediately so a future code is not sufficient on its own. It does not give you ownership of the number and it does close the easiest route back in.

Setting Two-Step Verification Immediately

The first thing to do after any transfer, in any format, is set your own two-step verification password. It does not evict existing authorisations, which is covered above, but it does stop a future code from being enough on its own. Combined with terminating other sessions it closes both routes rather than one.

The Three Compared

The same account, three wrappers, three different sets of consequences.

Choosing by Use

If the account is going straight into automation and the work is low value or short lived, the session file is the least friction and that is a legitimate reason to pick it. If a person is going to sit and use the account, TDATA saves a conversion. If the account will hold a channel, a group, or anything you would be upset to lose, take the number and make your own login.

One arrangement works well in practice: take the number for the accounts that hold anything, and accept files for the disposable sending accounts where the exposure is genuinely small. Treating every account with the same ceremony is how the ceremony gets abandoned.

Choosing by Value

A useful test is to ask what it would cost you if the previous holder still had access in six months. For a throwaway sending account the answer is almost nothing. For the account that administers your community it is everything, and no discount on a file format is worth that.

Converting Between Formats

All three directions are possible and none of them are free of consequences.

Session File to TDATA

Done with third party tooling that reads the authorisation and writes a desktop data folder. It works and it produces a second live copy of the same access, which is the part to notice: converting does not move the credential, it duplicates it. The original file is still valid afterwards.

Do the conversion offline and delete the intermediate copies afterwards. The temporary files these processes leave behind are the same credential in the same plain form, and they end up in temporary folders that get backed up.

TDATA to Session File

The same in reverse and with the same duplication. If the desktop data was protected by a local passcode, the conversion needs it, which is the usual reason a conversion that should work does not.

Number to Either

This one is not a conversion at all, it is a login. You sign in and the library or the client writes its own file. That is why it is the clean route: nothing is copied from anywhere, so nothing carries the previous holder's key or their cached contacts.

This is also the route to prefer when you are handing an account to somebody else, for the same reason in reverse: you are not sending them your cached contacts along with the access.

The Rule for All Conversions

Every conversion adds a copy and removes none. After converting, the correct next step is to terminate every other active session from within Telegram, which invalidates whatever the source file was carrying. Skip that and you have quietly doubled the number of live keys to your own account.

Write the termination step into whatever procedure you follow rather than relying on remembering it. It is the step that gets skipped, it is invisible when skipped, and its absence is only discovered when somebody else uses the key you left live.

On Conversion Tools

These tools take a live credential as input, which means running one is handing your account to whatever the tool actually does. Prefer something open that you or somebody you trust has read, run it offline, and treat any tool that asks you to upload the file to a website as a tool that now has your account. That is not a hypothetical risk, it is the plain reading of what uploading a key means.

Custody: The File Is the Account

Everything above collapses into one idea, and it is the one that costs people accounts.

Copies Are Uncountable

There is no register of how many copies of a session file or a data folder exist. Telegram cannot tell you and neither can the file. What you can see is the list of currently active sessions inside the app, which shows connections rather than keys, and that is the only visibility available.

This is the practical argument for the number and code route stated one more time, because it is the only part of this subject with a real asymmetry. Everything else is hygiene; this is arithmetic.

Storage

Keep them off synchronised drives, out of shared folders, and out of version control. A session file committed to a repository is a live credential in every clone of that repository, including the ones on machines you have never seen. Encrypt at rest if you keep more than a handful, because a folder of them is a folder of accounts.

Name them in a way that does not identify the account or its number. A folder listing is readable by anything with access to the folder, and file names travel further than file contents in backups, screenshots and support conversations.

The First Five Minutes After Receiving

Set your own two-step verification password. Terminate all other sessions. Change nothing else yet. Those two actions take a minute and close both the future-code route and the existing-key route, and doing them later is doing them after somebody else has had the opportunity.

A caveat on the second: terminating sessions from a brand new login sometimes runs into a waiting period, which is Telegram protecting accounts from exactly the kind of takeover you are performing legitimately. If you meet it, wait it out rather than working around it.

What to Do When One Leaks

Treat it as an account compromise rather than a file problem. Terminate other sessions, set or change two-step verification, and check what the account has been doing. Deleting your copy of the file achieves nothing, because the copy that leaked is somewhere else and still works.

Then work out how it left. A leak with no explanation will happen again, and in this area the explanation is usually mundane: a synchronised folder, an archive sent through a chat, or a repository that was public for an afternoon.

Buying Accounts Without Inheriting Problems

Most of what goes wrong when buying accounts is decided before the file arrives, and none of it is about price.

Ask What the Number Is

A real carrier number and a recycled virtual one are different products at similar prices. Virtual numbers get reused, have often been used for exactly this before, and are visible as such from the platform side even when they look identical to you. This is the single largest quality difference between two accounts that both say OLD on the label.

Ask directly and accept a straight answer. A seller who cannot say what kind of number is behind an account either does not know, which is its own answer, or would rather you did not.

Ask What the Account Has Done

Age on its own is worth less than the label suggests. An account that has existed for three years and never sent a message is old and empty; one that has exchanged messages, joined groups at human intervals and filled in a profile is lived in, which is the same distinction our guide to shared spam lists shows from the platform side. The second behaves differently and the difference shows on the first day of real use.

Check It Before You Rely On It

Log in, look at what is there, and run a small warm test before the account carries anything real. An account that fails quietly on its first cold batch takes the campaign with it, and the test costs an afternoon against a week of rework. Our guide to Telegram add member limits covers what that first batch should look like.

Test with something reversible. A first batch that is small and warm tells you what you need to know without putting a real campaign behind an account you have owned for an hour.

Assume the Seller Kept a Copy

Not as an accusation, as arithmetic: with the file formats they had the key and there is no mechanism that removes it from them. Behave accordingly, do the two custody steps immediately, and the assumption stops mattering. Sellers who understand this will not be offended by it.

Where We Sit

We supply OLD accounts in all three formats, and the reason the choice is offered rather than decided for you is the one this article is about: the right format depends on what the account is for. Real numbers rather than recycled virtual ones, because for this specific use that is the property that determines whether the account is worth anything. Current availability is on the pricing page.

Handing an Account Over

The same subject from the other side, which almost nobody writes about and which matters if you ever sell, transfer to a colleague, or wind down an operation.

Clean the Session First

A session file you hand over carries your entity cache: the usernames, phone numbers and names of people that account has dealt with. If that account was doing outreach, that is a partial list of who you contacted. Transfer via number and code where you can, and where you cannot, understand what you are including.

If you have to send a file, send it through something that expires rather than through a chat that keeps it forever. The archive sitting in a message history is a live credential in somebody else's account, indefinitely.

Terminate Your Own Access

If you are transferring an account properly, terminate your own sessions afterwards. Anything else leaves you with live access to an account somebody else is now responsible for, which is a liability rather than a convenience.

Say Which Format and Why

A buyer who receives a session file with no explanation usually does not do the custody steps, and the first thing that goes wrong is blamed on the account. Telling somebody to set two-step verification and terminate other sessions costs a sentence and prevents most disputes.

Common Failures and What They Mean

Four symptoms cover most of what actually happens, and each has one likely cause.

The Session Works Then Stops

Usually the authorisation was terminated, either by the previous holder tidying up or by the account owner reviewing active sessions. It can also be the account being restricted, which looks similar from a script but not from the app. Open the account in a client: if it opens, the session was killed; if it opens and cannot message strangers, that is a restriction and our guide on the Telegram spam restriction covers it.

Check the date it stopped against anything you know about the account's history. A session that dies the same week it was bought usually means the previous holder reviewed their sessions, which is the good outcome; one that dies mid campaign more often means the account itself is in trouble.

Two Places, Odd Behaviour

The same session running twice. Updates land in one process and not the other, operations fail with no pattern, and everything looks intermittent. One session, one process; if you need parallelism, use more accounts rather than more copies.

Converted TDATA Will Not Open

Most often a local passcode that did not come with the folder, and second most often a client version mismatch. Neither is recoverable from your side without the missing piece, which is why it is a question to ask before the transfer.

Login Asks for a Password You Do Not Have

Two-step verification is set and you were not given it. Number plus code is not enough here; the transfer is incomplete. This is a common way for a sale to be technically delivered and practically useless, and it is worth confirming before payment rather than after.

Ask about this before money moves rather than after. It is a one line question, it has a yes or no answer, and it is the single most common way an account transfer is completed on paper and not in practice.

Where This Fits in an Outreach Operation

Formats are a means. What they are a means to is having more than one account, because that is what actually decides capacity.

Why the Pool Is the Point

A single account's safe volume is low and tuning barely moves it, so reaching real volume from one account means operating outside safe pacing and losing it. Spreading the same total across several keeps each one comfortable, and a problem with one costs a fraction rather than everything. That is a sourcing decision rather than a settings decision.

The format question tends to absorb attention out of proportion to its importance because it is concrete and decidable in an afternoon, while sourcing is neither. It is worth noticing when a small decidable question is being used to avoid a large open one.

Managing the Pool

Several accounts each need their own session, pacing, cooldown tracking and network origin, and a mistake in one bleeds into the others through pattern similarity. Account Manager holds the sessions in one place, keeps each account inside its own observed limits and shows which ones are resting, which is the job once the count goes past two or three.

What Runs on Top

Mass DMs does the sending against that pool with pacing and message variation built in, and Member Adder handles adding with correct back-off. Neither removes Telegram's limits, which no product does; they spend the limits well, which is a different and achievable claim.

The Honest Order of Operations

Get the accounts right first, then the pacing, then the tooling. An operation built on recycled virtual numbers with perfect software fails in week one, usually inside the ceilings mapped in our guide to building a source list, and one built on good accounts with mediocre software mostly works. The format question in this article is the last five minutes of the first step, not the first step itself.

Frequently Asked Questions

What is a Telegram session file?

It is a SQLite database holding the authorisation key created when an account logged in, plus a cache of entities the account has seen. A freshly created empty one is 28,672 bytes and any SQLite tool opens it, because it is not encrypted. Anyone holding the file is logged in as that account with no code and no phone required, which is why it should be treated as the account itself rather than as a file about the account.

Session file or TDATA, which should I choose?

Session file if the account is going into a script, TDATA if a person will use it in Telegram Desktop, and number plus code if the account matters. The first two hand you a credential the seller created and can still hold a copy of; the third has you create your own authorisation, which is the only one of the three where the key in use did not exist before you made it.

Is a Telegram session file encrypted?

Not by default in the most widely used library. The authorisation key sits in plain form inside an ordinary database file, so storing session files in synchronised folders, shared drives or version control is equivalent to storing the passwords there. Encrypt them at rest if you hold more than a handful, because a folder of session files is a folder of accounts.

Does changing my Telegram password kill an old session?

No. Two-step verification protects new logins and does not invalidate authorisations that already exist, so somebody holding a copy of a session file keeps working after you change it. The action that removes their access is terminating other sessions from Telegram's own active sessions list, and doing both is what actually closes the door.

Can I convert TDATA to a session file?

Yes, in both directions, with third party tooling, and the important part is that converting duplicates the credential rather than moving it. The source stays valid afterwards. Terminate other sessions once the conversion is done, and be careful what you run: a conversion tool receives a live key, so anything that asks you to upload the file to a website now has your account.

Why does my session work in one place and fail in another?

Usually the same session is running in two processes at once. Both authenticate correctly because they are the same account, then interfere: updates reach one and not the other and operations fail with no consistent pattern. Use one session per running process, and add accounts rather than copies when you need to do more at the same time.