The update you keep postponing
There is a particular kind of message that template developers receive over and over. It goes something like this: "I know version 9 is out, and I know it is faster and fixes the bug I reported, but I spent an entire weekend setting up my menus and colours and ad slots. If I install the new file, do I lose all of that?"
For most of Blogger's history, the honest answer was yes. And because the answer was yes, a remarkable number of blogs are running templates that are two, three, even five versions behind — not because the owners do not want the improvements, but because the cost of getting them is a lost weekend.
The Blogger Template Version Merger exists to make that answer no. You give it the template running on your blog right now and the new version you just downloaded. It reads the settings you entered — your menus, your colours, your verification codes, your ad IDs — and writes them into the new file. What you download back is the new version, with all of your work already in place. The whole process takes about fifteen seconds and never leaves your browser.
Use the version merging tool here.
This article explains the tool, but it also explains the problem underneath it: why Blogger behaves this way, where your settings actually live inside a template file, what can and cannot be transferred, and how to run template updates safely from now on. If you have ever hesitated before clicking "Restore", this is written for you.
What the merger actually does
The tool performs one job with considerable care: it separates your data from the developer's code, and moves only your data forward.
A Blogger template file contains both. The developer contributes the structure, the styling and the logic. You contribute the values: the text of each menu link, the destination of each button, your brand colour, your logo URL, the HTML you pasted into a settings box. When a new version arrives, the developer's half has changed and yours has not. The merger keeps the new half and reinstalls the old half on top of it.
It does this in three passes:
- Layout settings. Every gadget in your Layout tab is matched to its counterpart in the new version, and its settings are copied across.
- Theme Designer choices. Every design variable — colours, fonts, logo, style switches — is matched by name and its value carried over.
- Site keys and IDs. Verification codes, AdSense and Analytics identifiers, and on Tooliqo themes your licence token and user-zone values.
After the merge it shows you a report: what moved, what is new in this version and therefore left at defaults, and what existed in your old template but no longer exists in the new one. Then it hands you a file to download.
Crucially, it never rewrites the new version's code. The improvements you updated for arrive intact.
Why Blogger loses your settings in the first place
This is not a bug, and it is not carelessness on Google's part. It is a consequence of a design decision made almost twenty years ago, and understanding it makes everything else about template updates clearer.
A brief history of the Blogger template
Blogger launched in 1999, built by a small San Francisco company called Pyra Labs, and was acquired by Google in 2003. In those early years a Blogger template was essentially one HTML page with a handful of special tags where posts would be injected. There were no gadgets, no drag-and-drop, and no settings to speak of. If you wanted a link in your sidebar, you wrote the anchor tag yourself.
The turning point came in 2006, when Blogger released a substantial rebuild, known at the time as Blogger Beta. It introduced Layouts: the drag-and-drop page-element editor that Blogger users still use today. With Layouts came a new template format built on XML, using tags in a custom namespace — the b: tags that anyone who has opened the HTML editor will recognise.
That format needed somewhere to store what each gadget contained. The decision was to store it inside the template file itself, alongside the code.
Four years later, in 2010, Blogger added the Template Designer (now Theme Designer), which let users change colours, fonts and widths through a visual interface. Those choices also needed storage, and they went into the same file — as a block of variable declarations at the top of the stylesheet.
In 2017 Blogger shipped a new generation of themes — Contempo, Soho, Emporio and Notable — along with an expanded template language. The storage model did not change.
Where your settings actually live
Open your template's XML in a text editor and you will find your own work scattered through it, mixed in among thousands of lines of code you never wrote.
Your menu links sit inside blocks like this, buried under the gadget that renders them:
<b:widget-setting name='text-0'>Home</b:widget-setting>
Your brand colour sits inside a comment block at the top of the stylesheet:
<Variable name="brand1" description="Brand colour" type="color" default="#1e40af" value="#c0392b"/>
Your Search Console verification code sits as an ordinary meta tag in the head. Your AdSense publisher ID sits in whatever slot the developer provided for it.
None of these live in a database, a settings table, or a separate configuration file. They live in the same document as the code. So when you upload a new template file, you are not just replacing the code — you are replacing the document that held your settings. They do not get overwritten by accident. They get replaced along with everything else, because they were never stored anywhere else.
Why WordPress users do not have this problem
It is worth drawing the contrast, because it explains why this tool has no obvious WordPress equivalent.
| Aspect | Blogger | WordPress |
|---|---|---|
| Where theme code lives | One XML file | Theme folder on the server |
| Where user settings live | The same XML file | The database, separately |
| Updating the theme | Replaces code and settings together | Replaces code only |
| Hosting required | None — Google hosts it | Yours to arrange |
WordPress separates presentation from configuration, so a theme update leaves your options untouched. Blogger bundles them, which is what makes it so simple to move a whole design between blogs as a single file — and what makes updating in place so awkward.
Each model trades one convenience for another. The merger gives Blogger users the WordPress-style benefit without giving up the single-file simplicity.
The anatomy of a Blogger template file
To understand what the merger can and cannot do, it helps to know what is actually in the file. A modern Blogger template has four distinct layers.
1. The skin
Near the top sits a <b:skin> element wrapping the entire stylesheet. Immediately inside it, in a comment block, is a list of variable declarations — the Theme Designer's storage. Each looks roughly like this:
<Variable name="bodyFont" description="Body font" type="font" default="normal 400 15px Inter" value="normal 400 15px Georgia"/>
Two attributes matter. default is what the developer shipped. value is what you chose. Theme Designer only ever writes to value, which is exactly the attribute the merger reads and carries forward.
2. Sections and widgets
The body of the template is divided into <b:section> containers — header, sidebar, footer, and in modern themes a dozen homepage zones. Sections hold <b:widget> elements, and each widget carries an ID such as HTML7 or LinkList10.
That ID is the hinge on which the entire merge turns. It is assigned by Blogger when a gadget is created, it is stable across exports, and a careful template developer keeps the same IDs from one version to the next precisely so that settings continue to map cleanly.
3. Widget settings
Inside each widget, before the markup, sits a <b:widget-settings> block. This is the gadget's saved state — everything you typed into it in the Layout tab.
For a links gadget you will see paired entries: text-0 and link-0, text-1 and link-1, one pair per row. For an HTML gadget you will see a single content entry holding the whole block you pasted, wrapped in CDATA so that the HTML inside does not confuse the XML parser.
This block is the single richest concentration of your work in the entire file, and it is what the merger transplants first.
4. Includables
After the settings comes <b:includable> markup: the actual template code that turns the settings into a rendered gadget. This is the developer's territory, it changes between versions, and the merger deliberately never touches it. That is precisely why a merged template still gains every improvement of the new release.
What moves across, precisely
Being specific here matters more than being reassuring, so here is the honest inventory.
Layout settings
Every gadget that exists in both files, matched by ID, has its complete settings block transferred. In practice that covers:
- Page menus, section menus and any nested sub-menus
- Social links and follow buttons
- Sidebar gadgets and their order-independent content
- Ad slots and any HTML you pasted into them
- Settings boxes — the key-and-value panels that modern templates use for bars, chatbots, redirects and contact details
- Homepage sections: services, testimonials, statistics, logos, pricing and the rest
- Post feed preferences such as how many posts show and which metadata appears
Theme Designer choices
Every variable present in both files is matched by name and its value copied. That typically includes your brand colours, background and text colours, dark-mode palette, body font, logo and favicon URLs, content width, and every style switch the developer exposed — post feed layout, button shapes, sidebar visibility, and feature toggles.
Site keys and identifiers
These are small, easy to lose and annoying to recover, so they get their own pass:
| Key | What it does |
|---|---|
| Google Search Console code | Proves you own the site to Google |
| Bing and Yandex verification | The same, for other search engines |
| DMCA verification | Content protection badge |
| AdSense publisher ID | Attributes ad revenue to your account |
| Analytics measurement ID | Keeps your traffic history continuous |
| Licence token (Tooliqo themes) | Activates a licensed template on your blog |
| Default post image and custom CSS | User-zone values on supported themes |
The tool skips anything that is still a placeholder. If your old file has YOUR CODE sitting in a slot, it will not overwrite the new version's slot with that.
What it deliberately leaves alone
Just as importantly:
- Template code. Stylesheets, scripts, includables and structure all come from the new version, untouched.
- Your posts and pages. These are not in the template file at all — they live in Blogger's own storage and are never at risk from a theme change.
- Gadgets that no longer exist. If the new version dropped a feature, its old settings are reported rather than forced back in.
- Direct edits you made to template code. This is the one real limitation, and it deserves its own discussion below.
Using tool merging versions, step by step
Link to the version merging tool
Step 1 — Back up what you have
In Blogger, open Theme, click the arrow beside Customise, and choose Backup. Save the XML somewhere you will find it again. This file is both your safety net and the first input to the merger, so this step is not optional.
Step 2 — Get the new version
Download the new template file from wherever you obtained the theme. Do not open it, edit it or paste anything into it. The merger wants it exactly as the developer shipped it.
Step 3 — Load both files
Open the merger. Drop your backup into the first box and the new version into the second. Both stay on your device; nothing is transmitted.
Step 4 — Choose what to move
All three categories are enabled by default, which is what most people want. Switch one off when you are deliberately adopting the new version's defaults — for example, if the developer has reworked the colour palette and you would like to see it as intended.
Step 5 — Merge and read the report
Click merge. Read the report rather than skipping it. The "new in this version" entries are worth noting: they tell you which features arrived in this release and are waiting at their defaults. The "dropped" entries tell you what no longer exists, which occasionally explains a change you would otherwise find puzzling.
Step 6 — Install and inspect
Download the merged file. In Blogger go to Theme → Edit HTML → Restore and upload it. Then look at your live blog properly: home page, a post, a static page, and the same three on a phone. Open the Layout tab and confirm your gadgets are populated.
If your blog is important to you, do this on a test blog first. Creating one takes a minute and removes all risk from the exercise.
How the matching works under the hood
The tool is deliberately conservative, and it is worth knowing why.
Matching by identifier, not by position
Gadgets are matched by their Blogger ID, never by their position in the file. This matters because new versions frequently reorder sections or insert new zones. Position-based matching would silently write your footer links into a header menu. ID-based matching either finds the right home for a setting or reports that it could not.
Matching variables by name
Design variables are matched by their name attribute for the same reason. If a developer renames a variable between versions, the old value is reported as unmatched rather than guessed at.
The safety check
Before offering anything for download, the merger validates the result: the document still terminates correctly, every CDATA block that opens also closes, and the gadget and section counts exactly equal the new version's. If any check fails, the tool produces nothing at all and tells you so.
This is a deliberate design choice. A tool that hands you a subtly broken template is worse than a tool that refuses, because the breakage may not surface until a visitor hits the page that depends on it.
Why the process happens in your browser
Nothing you load is uploaded anywhere. The file is read by your browser, processed in memory and written back to your downloads folder. No server sees it and no copy is retained.
This is not a slogan. Consider what a template file can contain: your Search Console verification code, your AdSense publisher ID, your Analytics ID, any API keys a login or comment feature needs, and on licensed themes an activation token tied to your purchase. A licence token in particular is worth something — it is the credential that makes a paid template run.
Uploading all of that to an unknown server in order to reorganise a text file is a poor trade. Browsers have been able to read local files and generate downloads for over a decade, so there is no technical reason to involve a server at all.
A useful habit generally: before uploading a template XML anywhere, ask what is inside it.
The manual alternative, and why it goes wrong
You can migrate settings by hand. Many people have. It is instructive to see why the approach fails at scale.
The manual routine is to install the new template, then reopen your old one in a text editor and copy each setting across one at a time. On a simple template with six gadgets that is twenty minutes of dull but manageable work.
On a modern template it is a different proposition. A feature-rich theme can carry seventy or more gadgets and over fifty design variables. That is hundreds of individual values, each needing to be located in one document and typed into the right place in another. The failure modes are predictable:
- Omission. One gadget in seventy gets missed, and nobody notices until a reader mentions a broken menu.
- Transcription error. A verification code loses a character and quietly stops working.
- Structural damage. A CDATA wrapper gets clipped during a copy, and Blogger rejects the file with an error message that points at a line number rather than a cause.
- Fatigue. Somewhere past the fortieth value, standards slip.
The task is mechanical, repetitive and unforgiving of small mistakes — precisely the profile of work that software does better than people.
A safe update routine
Whether or not you use the merger, these habits make template updates uneventful.
- Back up before touching anything. Every time, not just when you expect trouble.
- Keep dated backups. A folder of files named by date lets you return to any known-good state, not merely the most recent one.
- Use a test blog. One private blog, permanently available for trying templates, converts every risky change into a safe one.
- Read the changelog. Knowing that a release reworked the header explains what you are seeing afterwards.
- Update at a quiet hour. Not during your traffic peak, and not immediately before you go out.
- Check on a real phone. Responsive issues hide well in desktop browser emulation.
- Keep your own code in one place. If you add custom CSS or scripts, put them in the template's designated custom area rather than scattering them through the file. Everything in one known place survives an update; edits sprinkled across the code do not.
Troubleshooting
Blogger rejects the merged file
This almost always means the two inputs were not versions of the same template. Confirm that the new file is the same theme family as the old one, and that neither has been partially edited. The merger's safety check catches most of these before download, but Blogger's own parser is stricter still.
Very few settings moved
Read the report. If most entries say "new", the gadget IDs did not line up — which happens when the two files are different templates rather than different versions of one template. It can also happen if you rebuilt your Layout from scratch at some point, creating fresh IDs.
Colours look wrong after merging
Your old colour values moved into a new palette structure. If the developer reworked the design system, your previous values may now be applied to different elements. Run the merge again with Theme Designer switched off, adopt the new palette, and adjust from there.
A gadget is empty in the Layout tab
Check whether the report listed it as new. New gadgets ship with default or empty settings by design. Fill it in once, and every future merge will carry it forward.
Everything looks right but a feature does not work
Clear your browser cache and reload properly — Blogger and your browser both cache template assets aggressively. If the feature depends on a key or ID, confirm that value transferred by checking the report.
Honest limitations
No tool should oversell itself, so here is where this one stops.
Direct code edits do not transfer. If you edited the template's CSS or markup by hand — changing a colour in the stylesheet rather than in Theme Designer, say — that change lives in the code layer, and the code layer comes from the new version. Those edits must be reapplied. This is also an argument for making such changes through the template's custom CSS area, which is a setting and therefore does transfer.
Different templates do not merge meaningfully. The tool matches by identifier. Two unrelated templates share almost no identifiers, so almost nothing will move. It will tell you this rather than pretend otherwise.
Renamed variables are reported, not guessed. If a developer renames headerColor to topBarColor, the tool will not infer the relationship. It flags the old value as unmatched and leaves you to set it once.
It cannot rescue a corrupted file. If your backup is already damaged, the merger inherits the damage. Backups are only useful if taken while things work.
Frequently asked questions
Does this work with templates from other developers?
Yes. Layout gadgets and Theme Designer variables are part of Blogger's own format rather than any one developer's invention, so they transfer between versions of any template. On Tooliqo themes the tool goes further and also carries licence tokens and user-zone values, because it knows where those live.
Will it touch my posts, pages or comments?
No. Those are stored by Blogger, entirely separately from the template. Changing a theme has never affected them, and this tool operates only on template files.
How long does a merge take?
Seconds. The work is text processing on a file of one or two megabytes, which modern browsers handle without effort.
Can I merge the same pair of files twice?
Yes, as often as you like. Nothing is modified in place; each run produces a fresh output file from the two inputs.
Do I still need a backup if I use the merger?
Yes. The merger reduces the chance of a bad update; it does not remove the value of being able to return to exactly what you had. Back up every time.
What if I only want to move my colours?
Switch off Layout settings and Site keys, leaving Theme Designer enabled. The three categories are independent.
Does it work on a phone?
It will run, but choosing files and reading the report are considerably easier on a desktop, and you will be installing the result through Blogger's desktop interface anyway.
Why this matters more than it seems
It would be easy to file this under minor conveniences. It is worth arguing that it is not.
When updating carries a real cost, people stop updating. Blogs stay on old versions that load more slowly than they need to, miss accessibility improvements, lack the structured data that helps search engines understand them, and carry bugs that were fixed years ago. The gap widens quietly, release by release, until the template is too far behind to update casually at all.
Developers feel the same pressure from the other side. Knowing that every change imposes migration work on users encourages conservative releases and discourages the kind of structural improvement that would benefit everyone.
Remove the migration cost and both halves of that equation change. Updating becomes a fifteen-second task, so people do it. Developers can improve their work without apologising for it. The blogs that result are faster and better maintained — which serves readers, which is the point of the whole exercise.
Closing thoughts
The merger solves a problem created by an architectural decision made in 2006, for reasons that were entirely sensible at the time. Bundling settings with code is what makes a Blogger template portable as a single file, and that portability is a genuine strength of the platform. The cost only appears at update time, and it is a cost that software can absorb on your behalf.
So the practical advice is straightforward. Back up your template today, whether or not you plan to change anything. Keep your custom code in the areas designed for it. Keep a test blog. And the next time a new version of your template appears, install it — the weekend you were protecting is no longer the price of admission.
