Notes · 21 October 2026

Inside a Jimdo Creator site: what an export has to read

Jimdo is plain about it: “At Jimdo, there is also no option for creating a backup of your website yourself.” (Jimdo help). There is no blog export, no XML file and no ZIP. If you want your content somewhere else, the published site is the only copy you can read.

So we read one. This note uses a public Jimdo Creator blog, a German-language news blog with posts from 2010 to 2013, to show what a Creator site looks like from the outside and what trips up anyone copying it, by hand or with a script.

1. The sitemap is the inventory

/sitemap.xml on this site lists 1,615 URLs in one file. 1,202 of them are blog posts, which are easy to spot because the date is in the path:

/2012/12/31/die-besten-wünsche-zum-jahreswechsel-…/   post
/2012/12/30/hinweise-zum-grenzüberschreitenden-…/   post
/startseite/                                        page
/archiv-info24-blog24/                              page
/dezember-2013/                                     page (a monthly archive)

The other 413 are pages, and many of those are archive or category pages the owner built by hand. There are no <lastmod> dates, so the sitemap can't tell you which posts changed. The RSS feed (/rss/blog) has 18 items: fine for a reader app, useless as a list of everything you wrote.

2. A page is a stack of modules

Creator renders every page on the server as a column of j-module blocks inside #content_area. One post from December 2012 is made of these:

j-header          4   headings
j-text            8   paragraphs
j-textWithImage   8   a paragraph with a floated image
j-hr              5   dividers
j-spacing         2   empty space
j-facebook        1   ┐ from the template sidebar,
j-rss             2   ┘ not from the post

Two things follow. Read only #content_area, or every post picks up the sidebar's Facebook box and feed widget. And map each module type deliberately, because the generic ones hide real content:

3. Every image is called image.jpg

On that one post, the page loads 30 image URLs. Two are the template's header and favicon; of the other 28, 25 end in image.jpg and three in image.gif. What tells them apart is the path, which carries a file ID and the size Jimdo resized it to:

image.jimcdn.com/app/cms/image/transf/dimension=210x1024:format=jpg/path/…/image/i8d39…/version/1356172872/image.jpg
image.jimcdn.com/app/cms/image/transf/none/path/…/image/i8d39…/version/1356172872/image.jpg

The page asks for ten different dimension= values, mostly 210 to 320 pixels wide, for thumbnails and floated images. Replace the transf/… segment with transf/none and you get the file as it was uploaded. Save the thumbnail and the new site gets a blurry 210-pixel image.

The shared file name causes a second problem. Save images by name and they overwrite each other. Import them into WordPress and the importer may skip most of them as “already exists”, because it compares titles, which leaves the posts pointing at Jimdo's servers. We hit exactly that in testing (37 images on a Jimdo site) and wrote it up in our first note. The fix is a unique name per image.

4. Creator is not the new Jimdo

Jimdo runs two builders. Creator is the classic one with the blog and the module stack described here. The newer builder has no blog, and Jimdo says Creator content can't be moved into it: “The content on your Creator website can't be moved over to your Jimdo website.” (Jimdo help). So leaving Creator means leaving Jimdo, or rebuilding by hand.

A checklist before you copy anything

Decamp does all of this for Jimdo Creator sites and writes WordPress, Ghost, Webflow, Framer and Markdown files plus the redirects. See exporting a Jimdo site, Jimdo to WordPress, or the German page, Jimdo exportieren.

Paste a Jimdo address to count its posts, pages and images for free.