How to Export Your Telegram tdata Folder Safely in 2026

The most common mistake I see: people store their tdata backup in a shared folder, a cloud sync service, or a private git repository, then contact me three months later asking how someone got into their account. The tdata folder is not a settings file. It is a live session credential. Whoever has it has your account, no phone number required, no OTP needed. Treat the export step with the same discipline you apply to an SSH private key. It is not optional.

what you will end up with

Follow this guide to export telegram tdata safely and you will have an encrypted, integrity-verified archive you can move between machines, store offline, or keep as a disaster-recovery backup for your Telegram session. The archive is encrypted with age, a modern single-file encryption tool built for exactly this use case. The plaintext archive is checksummed with SHA-256 before encryption so you can verify the payload survived any transfer intact.

Total hands-on time is under 20 minutes. You need Telegram Desktop 4.14 or later, a terminal on any OS, the age tool installed, and your 2FA cloud password active on the account before you touch anything.

before you start

You need Telegram Desktop 4.14 or later. The folder structure is stable in recent releases but significantly different in builds before 4.0. You also need the age encryption tool installed on your OS and a 2FA cloud password already configured on the account under Settings > Privacy and Security > Two-Step Verification.

Do not skip the cloud password. It is stored server-side, separate from your tdata, and it is the one credential that survives even if you lose the tdata entirely. You also need your phone reachable for OTP in case the first login on a new machine triggers a device check. Have a USB drive or a path to encrypted offline storage ready before you begin. The archive must never land on an unencrypted cloud service in plaintext form.

# verify age is installed and working:
age --version
# expected: age v1.x.x (anything 1.0 or above works for this guide)

# Linux: confirm tdata folder location and completeness:
ls -lh ~/.local/share/TelegramDesktop/tdata/
# macOS:
# ls -lh ~/Library/Application\ Support/Telegram\ Desktop/tdata/
# Windows (PowerShell):
# Get-ChildItem "$env:APPDATA\Telegram Desktop\tdata\"

# a healthy tdata folder shows: one or more hex-named subfolders, a 'settings' file,
# and a 'key_datas' file. total size under 15 MB usually means the folder is partial.
# the hex subfolder is your session data; without it the export is not worth keeping.

the step-by-step

1. Set your 2FA cloud password before exporting anything.

Go to Settings > Privacy and Security > Two-Step Verification and set the cloud password now if it is not already on. Write it down and store it separately from the tdata backup you are about to create. If the exported tdata is ever compromised, a strong cloud password stops the attacker from adding a new device without it. Telegram’s SRP-based 2FA protocol means this password is never transmitted in plaintext.

2. Fully quit Telegram Desktop on the source machine.

This is the step most people skip, and it causes corrupted exports. On Windows, right-click the Telegram icon in the system tray and select Quit, or use Task Manager to kill the process. On Linux, run pkill -f [telegram](https://telegram.org/)-desktop. On macOS, right-click the Dock icon and select Quit. The main window closing is not the same as the app quitting. Telegram continues running in the background and holds write locks on the session files. Exporting a live tdata folder risks catching auth key files mid-write and producing an archive that fails silently on restore.

3. Locate the tdata folder and verify it is intact.

On Windows the path is %AppData%\[Telegram](https://telegram.org/) Desktop\tdata. On macOS it is ~/Library/Application Support/[Telegram](https://telegram.org/) Desktop/tdata. On Linux it is ~/.local/share/TelegramDesktop/tdata. Confirm you can see the hex-named subfolder (something like D877F783D5D3EF8C), a settings file, and a key_datas file. If only the settings file is present, there is no active session to export.

4. Move to the parent directory of tdata and create the archive.

The archive command must run from the directory that contains the tdata folder, not from inside it. On Windows using WSL or native Linux/macOS terminal, change to that directory first. This is where you export telegram tdata safely into a single transportable file, verify its integrity with SHA-256, and encrypt it with age before moving it anywhere.

# change to the directory that CONTAINS tdata (not into it)
# Linux example:
cd ~/.local/share/TelegramDesktop/

# create a timestamped compressed archive:
tar -czf tdata-backup-$(date +%Y%m%d).tar.gz tdata/

# verify the archive has a plausible size before trusting it:
ls -lh tdata-backup-*.tar.gz
# typical: 80 MB to 1.5 GB depending on media cache; under 2 MB means something went wrong

# generate and save a SHA-256 checksum:
shasum -a 256 tdata-backup-$(date +%Y%m%d).tar.gz > tdata-backup-$(date +%Y%m%d).sha256
cat tdata-backup-$(date +%Y%m%d).sha256
# copy this hash somewhere external; you will use it to verify the archive after any transfer

# encrypt the archive with age in passphrase mode:
age -p -o tdata-backup-$(date +%Y%m%d).tar.gz.age tdata-backup-$(date +%Y%m%d).tar.gz
# age prompts for a passphrase twice. use a strong one. store the passphrase separately.
# if you prefer recipient-key mode (stronger for long-term storage):
# age -r $(cat ~/.age/key.pub) -o tdata-backup-$(date +%Y%m%d).tar.gz.age tdata-backup-$(date +%Y%m%d).tar.gz

# confirm the .age file exists and has the same size as the original .tar.gz (roughly):
ls -lh tdata-backup-$(date +%Y%m%d).tar.gz.age

# delete the plaintext archive now that the encrypted version exists:
rm tdata-backup-$(date +%Y%m%d).tar.gz

# confirm only the .age and .sha256 files remain:
ls tdata-backup-$(date +%Y%m%d).*

5. Verify the encrypted archive decrypts correctly before moving it anywhere.

Before the plaintext archive is gone and the USB is on its way to another city, test the decryption. Run age -d tdata-backup-YYYYMMDD.tar.gz.age | shasum -a 256 and compare the output hash against what you saved in step 4. They must match exactly. If they do not, the archive was corrupted during the tar step or the age passphrase you entered the second time differed from the first. Re-run the archive and encryption steps with the correct passphrase. This test takes under two minutes. It is the one verification step that confirms you can actually restore from this backup.

6. Transfer only the .age file and the .sha256 file.

Move the .age file to your offline destination: a USB drive, an encrypted external disk, or a password-manager secure note for small keys. The .sha256 file goes alongside it. Neither file should touch an unencrypted cloud storage path. Do not email either file. If cloud storage is unavoidable, apply folder-level encryption before uploading, but offline storage is the simpler and safer default.

7. Do not commit tdata or its archive to any git repository.

This matters enough to say clearly. Git history is permanent. Even if you delete a file from a repository, anyone who cloned that repo before deletion still has the data. GitHub and GitLab run automated secret scanners, but those run after the push. By the time a flag fires, the key is already in every clone. OWASP’s top-ten broken access control guidance consistently names hardcoded secrets in version control as a primary credential-compromise root cause. A private repository is not safe either: CI/CD systems clone it, collaborators have full clone access, and repository visibility settings can change. The only correct policy is: tdata and its plaintext archive never enter a git tree.

8. Rotate the session if the export ever lands in an untrusted location.

If you have any reason to suspect the encrypted archive was accessed by someone who also had the passphrase, go to Settings > Devices on your phone and terminate all desktop sessions. Log back in fresh on the target machine using OTP. Generate a new tdata export under a new age key or passphrase. The old session key is dead the moment you terminate it from Devices. Even if someone decrypts the old .age file later, the key inside is worthless.

what can go wrong

The decryption test fails: hash mismatch after age decrypt.

The archive was either corrupted during the tar step or the age passphrase entered on the second prompt differed from the first. Delete the .age file and the archive, re-run from step 4, and be slow and deliberate when typing the passphrase both times. Paste from a password manager if you have one, because a passphrase mismatch between the two prompts is the most common reason for this failure. Age does not warn you of a mismatch during encryption. It only fails at decryption time.

The tdata folder is smaller than expected: under 15 MB.

Telegram Desktop may be installed but not logged in on this machine, or the tdata folder is from a default install with no active session. Open Telegram Desktop, confirm you are logged in and your chats load, then quit properly and retry the export. If the folder was manually cleaned or the cache was cleared, the session auth files should still be present (they are small), but confirm the hex subfolder exists before archiving.

Telegram shows a new login request or verification code prompt after import.

The session key in the tdata was revoked server-side between export and import. It can happen if you used the account on another device after the export, or if the import IP triggered a flag. Log in fresh with OTP on the target machine. Without a cloud password, a revoked session plus an unresponsive phone number leaves you locked out. With one set, you always have a second authentication path.

The age passphrase is lost.

There is no recovery path if the passphrase is gone. The file is encrypted correctly. That is the point. Store the passphrase in a password manager with a secure note tied to this specific backup, or use age with a recipient key pair where the private key is backed up separately. If you need to export telegram tdata safely in a team or multi-admin setting, recipient-key mode lets you encrypt once for multiple recipients, so one person losing their passphrase does not destroy the backup for everyone else.

how this looks on managed hosting

On a telegramvault cloud phone, the export process changes in two concrete ways. First, the tdata folder lives on the Android device, not on your laptop, so you access it through the STF browser session rather than a local file manager. Inside the STF window you open the Android file manager, go to the Telegram app data directory (typically under /data/data/org.[telegram](https://telegram.org/).messenger/files/ or accessible via a file manager app with root or system access granted), and pull the folder to your browser’s download path. Second, because the session runs 24/7 on a static Singapore mobile IP, you do not have to quit Telegram and race to finish the export before the session locks. The phone stays connected. You simply copy the folder state while the session is stable. The shasum and age steps are identical once you have the archive on your local machine. If you are on the telegramvault waitlist, ask during onboarding about the preferred export path for your specific device model, since the folder path varies slightly between Samsung, Pixel, and Xiaomi handsets in the farm.

recovery if you mess up

You deleted the plaintext archive before testing decryption and now the .age file fails.

Re-export from the source machine if it is still available. Quit Telegram Desktop, go back to step 3, and make a fresh archive. If the source machine is gone or the session was terminated, you need to log in fresh with OTP and start a new session. A tdata backup from a dead session has no restore value anyway.

You committed tdata to git by accident.

Act immediately. Force-push to rewrite history on branches you control, and use git filter-repo or BFG Repo-Cleaner to scrub the file from the full commit history. Treat the session key as compromised regardless: go to Settings > Devices on your phone and terminate all desktop sessions now, before finishing the history rewrite. Key revocation is the higher priority. History cleanup is damage control. If the repository was ever public, even for seconds, assume the key is in someone’s clone and revoke without delay.

You cannot receive an OTP to re-authenticate after a session revocation.

Telegram’s account recovery path is recover@telegram.org. Response times run days to over a week, and they do not expedite based on urgency. With a cloud password already set, you can log in from a new device via the “forgot phone” path without waiting for support at all. That is the practical reason to configure two-step verification before any export or migration. telegram" target="_blank" rel="noopener">EFF’s Surveillance Self-Defense guide for Telegram covers account recovery options in more detail.

Exporting tdata is the safe-copy step in a longer session lifecycle. The harder part is often the destination: what machine, and what is the IP? Getting the import right involves separate variables, particularly IP warming and geo-mismatch risk. How to import Telegram tdata without a ban covers those steps in full, and the two guides work together if you are migrating a session from one machine to another.

The IP that session key is bound to matters more than most people realize. telegram.org/mtproto/auth_key" target="_blank" rel="noopener">Telegram’s MTProto auth key specification describes how session keys are established in relation to connection context. In practice, a session that was active on a mobile carrier IP in Lagos will behave differently on restore than one from a datacenter VPS in Frankfurt. Dedicated vs shared mobile IPs covers what that difference looks like in session audit data and why static carrier IPs produce cleaner restore outcomes.

If you are thinking about what happens when Telegram’s automated systems flag the account regardless of how careful you were, why Telegram bans accounts is the most complete reference in this blog for understanding which signals trigger enforcement. Knowing the enforcement logic before you start a session migration is much more useful than reading it afterward.

For teams running more than a few accounts, manual tdata exports are operational friction that compounds fast. The answer at that scale is sessions on infrastructure where the IP is stable, the hardware is real, and the export path is known in advance.

final word

To export telegram tdata safely you need three things: a live 2FA cloud password before you start, an age-encrypted archive that you verify with shasum before and after transfer, and a strict policy of keeping tdata out of any git repository or unencrypted sync service. The commands are simple. The discipline around where the resulting file goes is the actual work. If you are managing accounts that cannot afford unplanned downtime, keeping a tested encrypted backup of each session is the difference between a two-minute restore and a multi-day support ticket.