rsd file-format project backup version-control

File format and project structure

Understanding how Site Designer stores your project helps you back it up, version-control it, and share it with collaborators.

The .rsd file

Site Designer saves projects as .rsd files (the extension stands for Responsive Site Designer).

A .rsd is a ZIP archive with a JSON payload inside. Renaming a copy to .zip and opening it shows the whole structure:

Entry	What it holds
`project.json`	The project itself: breakpoints, base selectors, custom fonts, class autocompletes, common values, the app version and build number it was saved with
`resources.json`	The index of imported assets
`components.json`	Components saved into the project
`library.json`	The project’s component library
`resources/`	The actual asset files, in the folders you created (`resources/images/`, and so on)
`palettes/`	Saved colour palettes

Assets are stored as real files inside the archive, not as base64 inside the JSON, which is why a project with large photographs produces a large .rsd.

Because everything travels in one file, backing up a project is copying that file, and sharing it with someone means sending one thing. No missing assets, no broken paths.

The .rsdtheme file

A .rsdtheme is what the Template Shop distributes and what File → New From Template installs. It is also a ZIP, containing one folder with three items:

Entry	What it is
`<Name>.rsd`	The project itself, exactly as described above
`<Name>.png`	The thumbnail shown in the Template Manager
`<Name>.data`	A one-line JSON manifest describing the template

That manifest is small and worth knowing about:

{"app_id":"ResponsiveSiteDesigner","framework":"vanillacss","mobileFirst":false,"name":"Visions","units":"rem"}

Two of those fields explain behaviour you meet elsewhere in this guide:

framework is recorded in the file. It travels with the project, which is why it cannot be changed later.
mobileFirst records the workflow direction. false here means this template was built desktop-down, the frameworkless workflow described in mobile first vs desktop down.

Why a single-file format?

Single-file project formats have clear advantages for the typical Site Designer workflow:

Easy backup: Copy one file to Dropbox, Time Machine, or an external drive.
Easy sharing: Email or Slack one file to a client or teammate.
No broken references: Assets travel with the project — no hunting for missing image files.
Simpler version control: A single .rsd file in a Git repository means your commits represent complete project snapshots.

The trade-off is file size: carrying every image and font inside the archive makes a .rsd as heavy as the assets it holds. A project with many high-resolution photographs runs to tens of megabytes. The Visions template, with 20 images, is 2.7 MB.

Assets inside .rsd files

Site Designer handles assets in two ways depending on how they were added:

Imported assets (images and fonts added through the Resources panel) are stored as real files inside the archive, under resources/, keeping the folder structure you gave them.
Externally linked assets (a URL typed straight into an image source) are not stored. They stay as references, so they break if that URL goes away.

Opening .rsd files

.rsd files are only useful inside CoffeeCup Site Designer. The archive holds the project, not a website: to get something a browser can serve, export the project to HTML and CSS.

To open a .rsd file: use File → Open in Site Designer, or double-click the file in your operating system’s file explorer (macOS Finder or Windows File Explorer).

Backup recommendations

Cloud storage: Place your project folder inside Dropbox, iCloud Drive, or Google Drive. All three maintain version history, giving you the ability to roll back to earlier versions of the .rsd file.
Git: For developer workflows, commit the .rsd before major changes. Git cannot diff the archive itself, but every commit is a full snapshot you can check out. If you want a readable diff, unpack a copy and commit project.json alongside it.
Manual copies: Before any high-risk operation (deleting pages, upgrading versions, bulk class renames), duplicate the .rsd file with a timestamp in the filename.