What Is a tdata Folder? Telegram Session Storage Explained (2026)

the short definition

The tdata folder is the local on-disk session storage directory used by Telegram Desktop on Windows, macOS, and Linux. It holds the encrypted MTProto authentication key that proves to Telegram’s servers that a logged-in client is legitimate, along with cached messages, contact data, and app settings. Copy this folder to another machine, point Telegram Desktop at it, and you inherit a fully authenticated session. No phone number. No OTP.

the longer explanation

Telegram Desktop shipped in 2013, the same year Pavel Durov launched the service. Unlike mobile clients, which store session credentials in platform-controlled hardware enclaves (Android Keystore on Android, Secure Enclave on iOS), the desktop client stores everything in a flat folder on the filesystem. On Windows the default path is %AppData%\Roaming\Telegram Desktop\tdata. On Linux it sits at ~/.local/share/TelegramDesktop/tdata. macOS puts it under ~/Library/Application Support/Telegram Desktop/tdata.

The critical file inside that folder is key_datas. It contains the client’s MTProto auth key, a 2048-bit value negotiated during the initial Diffie-Hellman key exchange with Telegram’s servers. That key is what authenticates every subsequent request. Telegram’s MTProto 2.0 protocol specification describes auth keys as long-lived credentials: they do not expire on their own, and Telegram does not rotate them unless you explicitly terminate the session from another device. Lift that file and you have a persistent login that survives password changes on your Telegram account.

The folder also contains numbered data files (the naming pattern looks like A, D, maps1, user_data, and several hexadecimal-named directories) that cache message history, media thumbnails, and settings. These are encrypted, but with a key derived from key_datas. If you have key_datas, you have everything. Without a local passcode set in Telegram Desktop’s settings, the encryption on key_datas relies on a machine-derived secret that is portable enough that the file works on a different machine with minimal friction.

Setting a local passcode in Telegram Desktop’s privacy settings is the single most important hardening step available. With a passcode, the auth key is re-encrypted under a PBKDF2-derived value. A stolen folder becomes much harder to use without it. Without one, copying the folder and pointing a fresh Telegram Desktop install at it produces a fully authenticated session in under a minute. This is not a theoretical risk. Infostealer malware has been exploiting this exact vector for years.

One thing many operators miss: the tdata folder also persists your local cache of messages received while the app was open. An attacker who copies it does not just get future access to your account. They get a snapshot of recent message history, group memberships, and contact lists at the moment of the copy. For anyone running channels, managing admin groups, or coordinating sensitive operations over Telegram, that cached data is often as valuable as the session credential itself.

why it matters for telegram operators

If you are running Telegram accounts at scale, tdata becomes a liability the moment the session lives on a shared or poorly secured machine. Infostealer malware, the category that includes tools like RedLine, Vidar, and Raccoon, specifically targets the tdata path because it is predictable and high-value. A single infected machine in an ops workflow can silently exfiltrate every session stored on it. The EFF’s Surveillance Self-Defense research on targeted device compromise treats filesystem credential theft as a primary vector precisely because it is silent and persistent. No notification. No warning. The session just gets copied.

The second risk is platform-level. Telegram’s anti-abuse systems look at behavioral signals including IP consistency, device fingerprint continuity, and session age. A session that authenticates from one city on Monday and from a datacenter IP in a different country on Tuesday is going to stand out. If you’re working with a tdata session that gets moved around or tunneled through recycled residential proxies, you are accumulating risk on every connection. Why Telegram bans accounts covers the full signal picture, but the short version is this: session portability is a double-edged sword. It makes tdata transfers possible, and it also makes inconsistent sessions visible to Telegram’s fraud detection.

For operators running large-scale channels, broadcast accounts, or business numbers, the real concern is continuity. A banned or hijacked session means downtime, reputation damage, and in some jurisdictions real legal exposure if the account is tied to a registered business number. The tdata model means the risk lives entirely on whichever machine holds the folder. Centralizing that risk, locking down access, and keeping the session on hardware that maintains a consistent IP and device profile is the operational answer to what the tdata architecture creates. Not paranoia. Just an honest look at how large the attack surface actually is.

common misconceptions

“Telegram is end-to-end encrypted, so tdata theft does not matter.”

This conflates two separate things. End-to-end encryption in Telegram applies to Secret Chats only. Regular cloud chats are encrypted in transit via MTProto, but stored server-side in a form Telegram’s servers can read. More importantly, none of that affects the tdata theft scenario. The auth key in key_datas is not a message decryption key. It is a session credential. Stealing it gives an attacker authenticated access to the account, including the ability to read cloud chat history, send messages as you, export contacts, join groups, and forward content. The encryption on the messages themselves provides no protection when the attacker is operating as a fully authenticated, legitimate-looking client.

“You need physical access to steal tdata.”

You do not. Infostealer malware exfiltrates the folder remotely. The path is consistent across installations, so any malware with standard filesystem read access can locate, compress, and upload it within seconds of execution. OWASP’s analysis of session hijacking attacks treats filesystem-based credential theft as a first-class vector precisely because predictable storage paths make targeting trivial. Physical access is not required. The malware just needs to run under the same user account as Telegram Desktop, which is the standard case on most Windows systems where the user is also the administrator.

“Copying tdata always produces a working session.”

Not always. There are several failure modes worth knowing. If the session was created on a Telegram Desktop version with a significantly different local storage schema, the new client may fail to parse it or overwrite it with a fresh session. More commonly, if Telegram’s backend detects a session being used from an IP or device fingerprint that looks inconsistent with its history, it may prompt for re-verification or terminate the session outright. A raw tdata copy dumped onto a datacenter server does not produce a guaranteed working session. Dedicated vs shared mobile IPs explains why IP consistency is part of what keeps a session alive long-term. The tdata copy is necessary but not sufficient. The environment it runs in matters too.

“You can tell if your tdata was stolen.”

Probably not, and definitely not in real time. Telegram does not push a notification when an existing auth key is authenticated from a new device. It does send a notification when a new auth key is created through the standard login flow, which is why you get that “New login from…” message when you sign in fresh. But loading an existing session via tdata reuses the existing auth key, so no new-login alert fires. The only detection mechanism available is the active sessions list under Settings > Privacy and Security > Active Sessions. A new entry from an unexpected device and IP is the signal, but only if the attacker has not already terminated other sessions to cover their presence. By the time most users think to look, the account has already been compromised.

a quick worked example

Say you are migrating a Telegram Desktop session from a Windows workstation to a Linux machine being used as a persistent session host. Here is the basic copy-and-verify workflow, including a check that confirms the folder is intact and that the destination IP is what Telegram will actually see:

# on the source Linux machine: archive the tdata folder
tar -czf tdata_backup.tar.gz -C ~/.local/share/TelegramDesktop tdata

# verify the archive contains key_datas before transferring
tar -tzf tdata_backup.tar.gz | grep key_datas
# expected output: tdata/key_datas

# transfer to destination (replace user@host with your target)
scp tdata_backup.tar.gz user@destination-host:~/

# on the destination machine: extract into the correct path
mkdir -p ~/.local/share/TelegramDesktop
tar -xzf ~/tdata_backup.tar.gz -C ~/.local/share/TelegramDesktop

# confirm file ownership and permissions
ls -la ~/.local/share/TelegramDesktop/tdata/key_datas
# should be owned by the user running Telegram Desktop, mode 600 or 644

# check what IP the destination will appear to Telegram as
curl -s https://ipinfo.io/json | python3 -m json.tool
# look at the "org" field carefully before launching the client

That last step matters more than most operators realize. If the org field comes back as AS14061 DigitalOcean or AS16509 Amazon, Telegram’s backend will see a session migrating to a datacenter IP. That is a flag. If it reads AS9506 Singtel or AS17645 M1, the session looks like it moved to a real mobile device on a carrier network. The difference is significant for account health, especially for accounts that have been active for months or years on mobile IPs. A sudden jump to a datacenter ASN after years of mobile-only authentication is exactly the kind of signal that triggers manual review or automated restriction.

how telegramvault relates

The value proposition of TelegramVault sits directly at the intersection of everything above. When a customer logs in once with their phone number, the resulting authenticated session (including the MTProto auth key) lives on a dedicated Android device in our Singapore farm, behind a real SingTel, M1, StarHub, or Vivifi SIM. That session never gets copied to a desktop machine, never runs through a rotating residential proxy pool, and never shares hardware with another customer’s account. The tdata problem (specifically the risk of a portable or inconsistent session getting flagged or stolen) is addressed by keeping the session physically anchored to one real device on one real mobile IP around the clock. Customers access their account through a browser-based STF session from wherever they are in the world, but the Telegram session itself never moves. The key_datas file stays on the same hardware it was created on. That is the cleanest possible answer to the attack surface the tdata architecture creates.

further reading

If you are new to how Telegram fingerprints and restricts accounts, why Telegram bans accounts on this blog covers the full signal set: IP type, session age, device fingerprint, behavioral velocity, and how those factors interact to produce the outcomes operators actually experience. Understanding tdata is step one. Understanding what Telegram does with the behavioral data tied to that session is step two.

The BYO number Telegram hosting explainer covers what it means to host a session you own, why number ownership matters for account continuity, and why third-party numbers create a different risk profile from your own registered number.

For the IP side of the picture, why Singapore mobile IPs gets into why mobile carrier ASNs, as opposed to datacenter or residential proxy IPs, affect how Telegram classifies a session over time. Singapore’s carrier diversity (SingTel, M1, StarHub, Vivifi all have distinct ASNs) also matters for operators with regional reach across Southeast Asia, South Asia, and the Gulf.

To go deeper on the authentication protocol itself, Telegram publishes the full MTProto 2.0 auth key generation specification, including the DH exchange, nonce handling, and session binding mechanics. Section 2 on key generation is directly relevant to understanding why the auth key is so long-lived and why its theft is so consequential.

final word

The tdata folder is not a flaw in Telegram Desktop. It is a deliberate design that makes session portability possible, and like most powerful tools, it cuts in every direction at once. The same mechanism that lets you migrate a session to a more stable host also lets an attacker do it silently, without your knowledge, from anywhere in the world. If you are running accounts that matter, know where the session lives, lock down the machine that holds it, and keep the IP it authenticates from as consistent as possible. If you want that handled for you, the TelegramVault waitlist is open now.