Guides / Finipage / Editing pages

How to Keep Versions of Your HTML Files Without Git

By the Qorlize team · Last reviewed

Finipage guide · Edit HTML files without code. Open Finipage

Sooner or later, someone asks for the version from last Tuesday. The client preferred the old headline, or a change you made broke the layout and you cannot remember what the page looked like before. If your folder holds index.html, index_final.html, index_final2.html and index_final_REAL.html, finding it becomes guesswork. A light routine prevents that, and for a small site it does not require Git.

A naming scheme that sorts itself

"Final" stops meaning anything the second time you use it. Dates do not. Put the date at the front of the name in year-month-day order, so the file list sorts in time order automatically:

landing_2026-11-03
landing_2026-11-07_new-pricing
landing_2026-11-11_client-feedback

A few habits make the names more useful:

  • Use 2026-11-07, not 7.11.26 or Nov 7. Only year-month-day sorts correctly as text.
  • Add two or three words saying what changed. "new-pricing" is far easier to find later than "v4".
  • If you save twice on the same day, add a letter or time: 2026-11-07b.
  • Avoid spaces and special characters in names you might later put online. Hyphens and underscores are safe everywhere.

Apply the date to the folder, not to the HTML file inside it. The page that goes online should still be called index.html, because that is the name web hosts serve by default; renaming it means renaming it back before every upload.

Copy the whole folder, and keep the original untouched

An HTML page is rarely one file. It points to images, a stylesheet, maybe a font folder and a script. If you copy only index.html into a backup, the backup records the text but not the images that were there at the time. Replace hero.jpg later and the old version will show the new photo, or a broken image if you renamed it. (The guide on how an HTML file is structured explains how those links work.)

So the unit you version is the folder. A simple layout:

my-site/
  00_original/          the files exactly as you received them
  2026-11-03_first-edit/
  2026-11-07_new-pricing/
  current/              the one you are working on

Two rules make this work. First, never edit 00_original. If a template, an AI tool or a previous developer gave you the files, that folder is your proof of what you started with, and the fallback when every later version has gone wrong. On Windows you can right-click the folder, open Properties and tick Read-only for its files as a reminder. Second, before any change you might want to undo as a whole (a new section, a colour scheme, a client revision round), copy current to a dated folder first, then edit.

Version history in Google Drive and OneDrive

If the folder lives in a synced cloud drive, you get a second safety net without doing anything. Both services keep earlier versions of files that change.

Google Drive. For files that are not Google Docs, such as HTML, CSS and images, open the file at drive.google.com, choose More, then File information, then Manage versions. From there you can download an older version or upload a new one. Google's help page says an older version may be permanently deleted after 30 days or once there are 100 newer versions, unless you mark it Keep forever from that version's menu.

OneDrive. Right-click a file at onedrive.com, or in File Explorer if the OneDrive app is syncing it, and choose Version history. The ellipsis next to a version lets you restore it, which makes it the current version and keeps the replaced one in the list. Microsoft's help page says it works with all file types and that version history is kept for 30 days. On work or school accounts, administrators set the rules.

Two limits matter for websites. Version history works file by file: there is no button to put the whole folder back to how it was on the 7th, so restoring a page plus its stylesheet plus three images means restoring each separately. And the retention window is short. Treat cloud history as an undo for recent accidents, and the dated folders as your real archive.

Comparing two versions

When you need to know what changed between two copies, let a tool mark the differences instead of reading them side by side.

  • VS Code (free): in the Explorer panel, right-click the first file and choose Select for Compare, then right-click the second and choose Compare with Selected. Changed lines are highlighted in two columns. From a terminal, code --diff old.html new.html does the same.
  • WinMerge on Windows, or similar free diff tools, can also compare two whole folders and list which files differ, which helps when you are not sure whether the change was in the HTML, the CSS or an image.

One thing can make a comparison look alarming. If one copy was saved by a different editor, it may have changed every line's spacing, line endings or character encoding even though the visible content barely changed. Finipage, for example, saves in UTF-8 and updates the meta charset line, so comparing an old EUC-KR file with its saved copy will show many changed lines. Most diff tools can ignore whitespace, which takes care of the spacing part.

When Git or GitHub Desktop is worth it

Git is a version control system. Each time you commit, it records a snapshot of the whole folder with a short message, and you can see exactly what changed in every file between any two snapshots. GitHub Desktop is a free app for Windows and macOS that does this with buttons instead of commands.

It is probably worth learning if:

  • the site has several pages and files that change together;
  • you edit it every week, not twice a year;
  • more than one person changes the files;
  • you already host it on GitHub Pages, where your files live in a Git repository anyway (see publishing an HTML page online).

For a single landing page you touch once a month, dated folders are simpler and easier to explain to the next person.

What browser auto-backup does, and does not, protect

Many browser-based editors save your work inside the browser as you go. Finipage, for example, keeps an automatic backup in the browser every few seconds, so if you close the tab by accident or the browser crashes, reopening the editor brings your edits back. While you are working, Ctrl+Z also undoes up to 50 steps. Both are useful, and neither is a version archive.

Browser storage belongs to one browser on one device. It does not travel to your laptop if you started on your office PC, and it does not exist in a different browser on the same computer. It is also deleted when you clear browsing data or site data, which some cleanup tools and company IT policies do automatically. MDN also notes that browsers can remove stored data from sites when the disk is nearly full, and that Safari, with cross-site tracking prevention on, deletes script-created data for sites you have not interacted with in seven days of use.

So treat auto-backup as protection against a closed window, not against losing the file. The real copy is the one you saved to disk. Save it into your current folder, and copy that to a dated folder before the next big change.

A quick routine: before a revision round, copy current to a dated folder. Edit and save. If the folder is in Google Drive or OneDrive, recent mistakes can also be undone from version history.

Ready to make the next change? Open the file in the editor, or start with editing an HTML page without code if you are new to it.

Want to try it on your own file? Open the Finipage editor. It runs in your browser and your file stays on your device.