Introducing CLDF: An Open Data Format for Climbing Apps
You’ve spent two years logging every session. Hundreds of climbs. Flash ascents, project sends, grade pyramids that finally show progress. Then you switch phones, or try a different app, or want to share your season with a training partner.
And you discover your data is trapped.
Every climbing app stores data in its own internal format. There’s no standard way to move a climbing logbook from one app to another. No equivalent of what GPX did for GPS tracks or what iCalendar did for events. Your climbing history is locked inside whatever app you started with.
We built CLDF to fix that.
What Is CLDF?
CrushLog Data Format (CLDF) is an open specification for packaging climbing performance data into a portable, self-contained archive. A .cldf file is a gzipped bundle of JSON files — one for each data domain — that any app can read or write.
session-export.cldf/
├── manifest.json # Export metadata and stats
├── locations.json # Gyms, crags, outdoor areas
├── sectors.json # Sub-areas within locations
├── routes.json # Route/problem definitions
├── sessions.json # Climbing session records
├── climbs.json # Individual climb attempts
├── tags.json # Predefined and custom tags
├── checksums.json # SHA-256 integrity hashes
├── media-metadata.json # Photo/video references
└── media/ # Embedded media files
├── photos/
└── videos/
The format is fully documented and open-source under Creative Commons Attribution 4.0.
Why Not Just Use JSON?
CLDF is JSON — but with a defined structure. A raw JSON dump of a database tells another app nothing about what the fields mean, which ones are required, or how entities relate to each other. CLDF provides:
- A schema for every entity — locations, sessions, climbs, routes, tags, media
- Standardized enums — finish types (
flash,onsight,redpoint,project), session types (sportClimbing,bouldering,boardSession), belay methods, rock types - Multi-system grades — store grades in Font, V-Scale, French Sport, YDS, and UIAA simultaneously
- Integrity verification — SHA-256 checksums for every file in the archive
- Versioned compatibility — semantic versioning with clear migration paths
When an app opens a .cldf file, it knows exactly what it’s looking at.
The Data Model
CLDF captures what climbers actually care about tracking.
Climbs
The core entity. Each climb records the route name, type (boulder or route), grade, finish type, number of attempts, and optional details like hold color (for indoor), belay method, falls, duration, rating, and personal beta notes.
{
"id": 42,
"date": "2026-03-15",
"routeName": "Moonlight Sonata",
"type": "route",
"finishType": "redpoint",
"grade": {
"french": "7b+",
"yds": "5.12c"
},
"attempts": 4,
"rating": 5,
"notes": "Finally sent. Crux is the dyno at the third bolt.",
"tags": ["overhang", "dyno", "crimpy"],
"mediaIds": ["img_001", "vid_001"]
}
Sessions
A session groups climbs into a day’s activity. It records the location, time range, session type, weather conditions, climbing partners, and approach time.
Locations
Indoor gyms and outdoor crags, with optional GPS coordinates, country, rock type (15 supported types from sandstone to volcanic tuff), and terrain info. Locations can contain sectors — sub-areas like specific walls in a gym or sections of a crag.
Routes
Predefined route definitions with grades in multiple systems, protection ratings (from bombproof to x-rated), quality ratings, and characteristics like trad vs. bolted.
Grades Without the Arguments
One of the trickier parts of the spec: grading systems. Climbers use different systems depending on where they climb and what discipline. A V5 boulder in the US is roughly a 6C in Fontainebleau. A 5.12a sport route in Yosemite is a 7a+ in France.
CLDF doesn’t pick a winner. Every climb and route can store grades in multiple systems simultaneously:
"grade": {
"vScale": "V5",
"font": "6C"
}
The spec defines conversion tables between systems, but apps are free to display whichever system the user prefers.
Three Ways to Handle Media
Photos and videos are the hardest part of data portability — they’re large, platform-specific, and privacy-sensitive. CLDF offers three strategies:
Reference — Store only metadata (filename, asset ID, hash). Tiny file size, but the receiving app needs to match files from the device’s media library.
Thumbnail — Include 200x200 JPEG previews. Good for previewing imported data before committing.
Full Export — Embed complete photos (JPEG, 90% quality) and videos (MP4/H.264). Largest archive, but fully self-contained.
The choice is recorded in manifest.json, so the importing app knows what to expect. Media metadata includes EXIF data, GPS coordinates, and platform-specific asset IDs for smart matching during import.
Privacy by Design
CLDF treats privacy as a first-class concern:
- GPS coordinates can be truncated to reduce precision
- EXIF data (camera serial numbers, owner info) can be stripped
- Face detection data is never exported
- Partner names are optional
- Media location embedding is configurable
You choose how much you share. Export a .cldf for your training partner with full location data, or export one for a public forum with coordinates stripped.
Data Integrity
Every .cldf archive includes checksums.json — a manifest of SHA-256 hashes for every file in the bundle. This catches corruption during transfer, verifies that an archive hasn’t been tampered with, and ensures imports are working with clean data.
{
"algorithm": "SHA-256",
"files": {
"manifest.json": "a1b2c3d4e5f6...",
"climbs.json": "f6e5d4c3b2a1...",
"sessions.json": "1a2b3c4d5e6f..."
}
}
Import Conflict Resolution
When importing a .cldf into an app that already has data, conflicts are inevitable. The spec defines four strategies:
- Skip — don’t import conflicting records
- Overwrite — replace existing records
- Duplicate — create new records alongside existing ones
- Merge — intelligent merge (application-specific logic)
The importing app chooses the strategy. CLDF just ensures the data is structured enough to make that choice possible.
Building on CLDF
The spec is designed for extensibility. Custom fields are supported on locations and climbs — apps can add their own data without breaking compatibility. New enum values and optional fields can be added in minor versions without breaking existing importers.
If you’re building a climbing app, training platform, or analysis tool:
- Read the full specification
- Use the JSON schemas for validation
- Check the example archives for reference implementations
CrushLog already supports full CLDF import and export. We’d love to see other apps adopt it — the goal is interoperability, not lock-in.
Your Data Is Yours
We built CrushLog around a simple principle: your climbing data belongs to you. CLDF is the technical expression of that principle. It means you can always get your data out, move it somewhere else, back it up in a format that will outlast any single app, or hand it to a coach in a structure they can actually work with.
The spec is open. The format is documented. Your sends are portable.
CLDF is open-source under CC BY 4.0. Contributions and feedback welcome on GitHub.