How PolyTrack Track Codes Work Under the Hood
Every track on PolyTrackCodes exists as a single string of characters. Copy it, paste it into the game, and a full 3D racing track materializes from what looks like random gibberish. But that string is not random — it is a compressed, encoded blueprint containing every piece of geometry, every checkpoint, every ramp angle, and every surface type in the track.
This article breaks down how track codes actually work: what format they use, what data they encode, how different versions differ, and why some codes fail to load.
What Is a Track Code?
A PolyTrack track code is a serialized representation of a track's geometry encoded as a text string. When you build a track in the editor and export it, the game takes every piece you placed — its type, position, rotation, and properties — and converts that structured data into a compact string that can be shared as plain text.
Think of it like saving a spreadsheet: the file stores row/column data, cell formatting, and formulas. A track code stores block types, 3D coordinates, orientation angles, and surface properties.
Here is what a typical track code looks like:
PolyTrack24pdDQnlgCCCAAA9KZhm1nib5GVKqgfTURNjIXb50P...
The string is usually between 100 and 2000+ characters long, depending on track complexity.
Track Code Versions
PolyTrack has gone through several major updates, and the track code format has evolved with each one. You can identify the version by looking at the prefix of the code:
| Version | Prefix | Era | Status |
|---|---|---|---|
| v3 | v3_ or starts with raw data | Early PolyTrack (2023) | Legacy, still loadable |
| PolyTrack1 | PolyTrack1 | Mid-era (2024) | Supported but outdated |
| PolyTrack2 | PolyTrack2 followed by version digits | Current (2025-2026) | Active standard |
v3 Format (Legacy)
The earliest public format. v3 codes are typically shorter and encode a simpler set of track pieces. The block library was smaller, so fewer bits were needed per piece. These codes are still loadable in current versions of the game, but tracks built with v3 may display slightly different physics behavior because the engine has been updated since these tracks were created.
PolyTrack1 Format
The first major format revision. PolyTrack1 introduced a richer block library (more curve types, more surface materials) and a more efficient encoding scheme. Codes are generally longer than v3 but still relatively compact.
PolyTrack2 Format (Current)
The active standard as of 2026. PolyTrack2 codes include support for all current editor features: banked curves, Y-intersections, smooth transitions, checkpoints, start/finish gates, and the expanded surface material system.
A PolyTrack2 code typically begins with PolyTrack2 followed by a version identifier (like 4pd) and then the encoded track data.
What Data Does a Track Code Contain?
Each track code encodes the following information for every block in the track:
1. Block Type ID
Every piece in the editor has a unique numeric identifier. A straight road piece, a left-banked curve, a checkpoint gate, a ramp — each has its own ID. The code stores which block type was placed.
2. Position (X, Y, Z)
The 3D coordinates of each block in the track's grid system. PolyTrack uses a discrete grid, so positions are stored as integers rather than floating-point numbers, which significantly reduces code length.
3. Rotation
The orientation of each block. Blocks can be rotated in 90-degree increments around the vertical axis, and some blocks support additional pitch/roll orientations for elevated or banked geometry.
4. Surface Properties
Some blocks carry additional data about surface material (normal road, ice, boost pad, etc.) which affects the physics of cars driving over them.
5. Metadata
The code header contains track-level metadata: format version, grid dimensions, and potentially the track name and creator tag.
The Encoding Process
The raw track data (block types, positions, rotations) starts as structured binary data. Converting it to a shareable text string involves several steps:
Step 1: Serialization
The track's block list is converted into a flat binary sequence. Each block occupies a fixed number of bits based on the format version.
Step 2: Compression
Repeated patterns are compressed. If a track has 20 identical straight pieces in a row, the encoding does not store all 20 individually — it uses run-length encoding or similar techniques to compress repetition.
Step 3: Base Encoding
The compressed binary data is converted to a text-safe string using a base encoding scheme. PolyTrack appears to use a variant of Base62 encoding (using A-Z, a-z, 0-9) which produces URL-safe strings without special characters.
This is why track codes look like alphanumeric gibberish — they are binary data rendered in human-readable characters.
