A Notepad++ crash becomes frightening when the reopened tab is empty or an edited remote file appears to have lost its content. Recovery is often possible, but the correct location depends on whether the document was unsaved, saved locally, or opened through the NppFTP plugin.
The most important rule is simple: stop changing files and copy the recovery data before experimenting. Restarting applications repeatedly, reinstalling Notepad++, clearing temporary files, or reconnecting a plugin can overwrite the best available copy.
Preserve the Current State First
If Notepad++ is still open but behaving incorrectly, do not save a blank tab over the original file. Use Task Manager only when the application is completely unresponsive; otherwise, first copy any visible content into a new file.
Before reopening the affected document:
- Disconnect automatic deployment or FTP synchronization.
- Copy the Notepad++ configuration and backup folders to another location.
- Copy the project’s local folder if one exists.
- Record the original file path and approximate modification time.
- Check whether another editor, browser, build output, or server still has a readable copy.
Work only on duplicates. Preserve timestamps where practical because they help distinguish the newest valid candidate from an older or empty file.
Check Notepad++ Session Snapshot Backups
Current Notepad++ versions can keep periodic snapshots for unsaved or modified tabs when session snapshot and periodic backup is enabled. The normal per-user backup location is:
%AppData%\Notepad++\backup
Press Win + R, paste that path, and press Enter. Copy the entire backup folder to the Desktop or another safe location before opening candidates.
Snapshot filenames may include the original name plus a timestamp-like suffix. Sort by Date modified, then inspect copies in a text editor. Do not assume the largest or newest file is correct; compare the content with the expected project state.
Notepad++ session information is commonly stored near:
%AppData%\Notepad++\session.xml
session.xml can identify which files or backup snapshots were open, but editing it carelessly may damage session restoration. Copy it first and read the duplicate as text.
If Notepad++ runs in portable or local-configuration mode, its settings may be beside notepad++.exe rather than under %AppData%. Look for a backup directory and configuration XML files in the portable installation folder.
Confirm Backup Settings for Future Sessions
After recovery—not before copying current evidence—open Settings → Preferences → Backup. Check whether Enable session snapshot and periodic backup is enabled and review the backup interval.
This feature helps recover unsaved tabs, but it is not version control and not a complete backup system. Snapshot behavior can change when a tab is closed normally, a file is saved, settings are reset, or cleanup software removes data.
Use a dedicated backup location only if it is reliable and has enough space. Avoid pointing active snapshots at an unstable removable device or a sync folder that creates conflicts while files are changing rapidly.
Recover Files Opened Through NppFTP
The original version of this guide focused on the NppFTP plugin. NppFTP downloads a working copy to a cache before editing and uploads changes back to the remote server. If Notepad++ crashes during that process, a usable local cache copy may remain.
A commonly used location is:
%AppData%\Notepad++\plugins\config\NppFTP\Cache
Directory capitalization can differ, and plugin versions or portable installations may store configuration elsewhere. If the exact path does not exist, inspect these locations without creating a new empty folder:
%AppData%\Notepad++\plugins\config
<Notepad++ portable folder>\plugins\config
Copy the complete NppFTP configuration/cache tree before reconnecting. Cache directories may mirror server names and remote paths, which helps locate the correct file.
Never upload the first candidate immediately. Open the local copy, confirm its encoding and content, compare it with the server version, and save a separate recovery copy. Upload only after you know which version is authoritative.
Check the Original Local File and Previous Versions
If the document had already been saved locally, the filesystem copy may be intact even when the restored editor tab is blank. Open File Explorer, locate the original, and check its size and modification date.
Right-click the file or its parent folder and inspect Properties → Previous Versions. Results appear only when File History, restore points, a backup product, or supported shadow-copy configuration has captured the item.
OneDrive, Dropbox, Google Drive, Git hosting, and network storage may provide version history or a recycle bin. Use the provider’s web interface where possible so you can review versions before restoring over the current file.
For source code, check Git even if the latest changes were not committed. The last committed revision will not contain unsaved work, but it provides a safe baseline and reduces how much must be reconstructed.
Search Temporary Locations Carefully
Windows and applications may leave temporary copies under:
%TEMP%
Sort by modification time and search for likely filename fragments or extensions. Copy candidates elsewhere before opening them.
Temporary directories contain unrelated application data. Do not run unknown executables or scripts found there. Text-search tools should treat files as data, and antivirus protection should remain enabled.
A broad disk search may locate editor backups, renamed copies, deployment staging files, or compiler/build output. Search for a distinctive sentence, function name, or configuration key rather than relying only on the original filename.
Inspect the Remote Server Without Overwriting It
For an FTP/SFTP-edited file, download the current server version to a new local filename. Do not open the remote file through the same automatic-edit workflow until caches are preserved.
Check whether the host offers:
- Control-panel file backups
- Daily snapshots
- Deployment releases
- A recycle or trash directory
- Git-based deployment history
- Application-level revision storage
An upload interrupted midway can leave a zero-byte or partial remote file. A provider backup may be safer than trying to reconstruct it from the broken server copy.
Prefer SFTP or another encrypted deployment method over plain FTP. Better still, edit locally, commit to version control, test, and deploy a known revision. Directly editing production files through an FTP plugin creates a single fragile working copy.
Avoid Actions That Reduce Recovery Chances
Until all candidates are copied, avoid:
- Saving an empty restored tab over the original path.
- Reinstalling or resetting Notepad++.
- Running disk-cleanup or “optimizer” utilities.
- Clearing
%AppData%,%TEMP%, or plugin caches. - Reconnecting NppFTP with automatic upload enabled.
- Restoring one version directly over another without a copy.
- Installing random file-recovery software onto the affected drive.
If a local file was deleted from an SSD, continued use may allow TRIM and normal writes to reduce recovery chances. For irreplaceable data, stop using the device and consult a qualified recovery specialist rather than installing tools on it.
Build a Safer Editing Workflow
Enable Notepad++ session snapshots, but combine them with proper controls:
- Edit in a local project directory.
- Commit meaningful checkpoints to Git.
- Keep automated, versioned backups.
- Deploy through SFTP, CI/CD, or release artifacts.
- Verify the deployed file before removing the local working copy.
- Test restores periodically.
For important production changes, a snapshot feature is the last line of convenience—not the first line of protection.
Recovery Order to Remember
Start with copied Notepad++ backup and session data, then inspect NppFTP cache, the original local file, cloud or File History versions, temporary files, and server-side backups. Compare every candidate before restoring.
A crash does not always mean the text is gone. Acting slowly, preserving evidence, and avoiding automatic overwrite paths gives you the best chance of recovering the correct file.