ROFL File Documentation

Summary

A ROFL file is a League of Legends replay, not a video. It records the match’s inputs and events so the League client can re-simulate the game, which is why it is only a few megabytes and only plays inside League of Legends itself. Double-click it (the game launches and plays it back) or use in-client Match History. A replay works only on the patch it was recorded on. Its default MIME type is application/octet-stream.

Technical details

FeatureValue
Full nameLeague of Legends Replay
File extension.rofl
MIME typeapplication/octet-stream
Format typeProprietary binary replay (recorded game state, not video)
DeveloperRiot Games, Inc.
Introduced2016 (in-client replay system)
Open standardNo
Byte orderLittle-endian (length fields)
Magic number52 49 4F 54 (ASCII RIOT) at offset 0
Signature block256-byte signature following the magic (bytes 6–261)
MetadataJSON block of end-of-game per-player stats
PayloadEncoded stream of game commands and state the client replays
Contains videoNo — no pixels or footage; the engine re-simulates the match
Typical sizeA few MB for a 30-minute game
Patch-boundYes — plays only on the client version it was recorded on
Default location (Windows)Documents\League of Legends\Replays
Opened byLeague of Legends client only
Related extensions.wotreplay (comparable game-replay format)
File signature (magic bytes)
52 49 4F 54

At offset 0 the four bytes 52 49 4F 54 spell ASCII RIOT, followed by two bytes and then a 256-byte signature block (bytes 6–261). After that, a fixed set of little-endian length and offset fields point to a JSON metadata section (per-player end-of-game stats) and to the proprietary payload of recorded game commands. The payload holds game state, not video frames, so a ROFL only replays inside the League of Legends client on its original patch.

What is a ROFL file?

A ROFL file is the replay format of Riot Games’ League of Legends, introduced with the in-client replay system around 2016. The single most important fact about it is what it is not: it is not a video. A ROFL contains no pixels and no footage. Instead it stores the recorded sequence of game data, the player inputs, unit positions and events, that the League of Legends engine feeds back through itself to re-simulate the match exactly as it happened. That design is why a full 30-minute game is only a few megabytes, a tiny fraction of what a screen recording of the same match would take, and why the file can only be opened by the League client that knows how to run the simulation.

The file begins with the ASCII magic RIOT and carries a JSON block of end-of-game statistics that outside tools can read, but the bulk of it is a proprietary encoded stream Riot does not publicly document. Because playback is a re-simulation rather than a video decode, the format is tightly bound to the game version. The sections below cover the header layout, how the metadata and payload are located, why replays expire on a patch update, and why there is no such thing as a ROFL-to-MP4 converter.

The RIOT magic and the signature block

Every ROFL file opens with a four-byte signature at offset 0: the bytes 52 49 4F 54, which are the ASCII characters RIOT. A parser checks for this magic before reading anything else; a file that does not start with it is not a valid replay. Two bytes follow the magic, and then a 256-byte signature block occupies roughly bytes 6 through 261. That block is a cryptographic signature over the replay data that Riot uses to detect tampering; community tools simply skip past it, because the interesting structural information sits immediately after.

offset 0    52 49 4F 54            "RIOT"  (4-byte magic)
offset 4    XX XX                  2 bytes
offset 6    ... 256 bytes ...      signature block (skipped by readers)
offset 262  length / offset fields (little-endian)

All the multi-byte integers in the header that follows are stored little-endian, the natural byte order for the Windows client that writes them. This is the opposite of the big-endian convention used by container formats like MP4, and it is a small reminder that ROFL is an application-private format designed for one program, not an interchange standard.

The length and offset fields

Directly after the signature block comes a compact table of length and offset values that acts as the file’s directory. Rather than laying sections out at fixed positions, the header records where each section starts and how long it is, so the reader jumps straight to what it needs. The fields, all little-endian, are:

FieldTypeMeaning
HeaderLengthuint16size of the header block in bytes
FileLengthuint32total length of the entire file
MetadataOffsetuint32byte offset to the JSON metadata section
MetadataLengthuint32length of the metadata section
PayloadHeaderOffsetuint32byte offset to the payload header
PayloadHeaderLengthuint32length of the payload header
PayloadOffsetuint32byte offset to the start of the replay payload

This offset-and-length approach is the same idea a MP4 uses when its sample tables point into the media blob: the index is small and separate, and the reader follows pointers rather than assuming a fixed layout. It also lets Riot grow the metadata or payload without breaking the parser, since nothing downstream is hard-coded to an absolute position.

The JSON metadata block: readable end-of-game stats

The MetadataOffset/MetadataLength pair points at a block of UTF-8 JSON, and this is the one part of a ROFL that is human-readable and stable enough for third-party tools to parse. It holds the end-of-game scoreboard: game length, the patch version the replay was recorded on, and a per-player list of champion, summoner name, kills/deaths/assists, items, gold, damage and the other columns you see on the post-game screen. Replay-stats websites and community parsers work entirely from this JSON; they never touch the simulation stream, because they only need the numbers, not the ability to play the match back.

The JSON stores the game version explicitly, which matters for the next section: it is the field that tells the client, and any tool, exactly which patch the replay belongs to. If that version does not match the installed client, the replay will not play, and the version string is how you can tell why before you even launch the game.

Why a ROFL expires when the patch changes

Because a ROFL is played by re-simulation, it depends on the game logic being identical to when it was recorded. The file stores what the players did, not what appeared on screen. To turn those recorded commands back into a match, the engine must apply the same champion abilities, item stats, cooldowns, map layout and balance numbers that were live at record time. When a new patch ships, Riot changes exactly those values, so replaying old commands against the new logic would desynchronise: a spell that used to hit now misses, a unit that used to die now survives, and the simulation diverges from what really happened.

Rather than let a replay play back wrongly, the client refuses to open a ROFL whose stored version does not match the current patch. This is not corruption and there is no repair for it; it is a direct consequence of the re-simulation model. Riot supports replays only for the current patch, so a replay is effectively a short-lived recording that expires on the next update. If you want to keep a match permanently, you have to capture it as video while it plays, described next.

Why there is no ROFL-to-MP4 converter

The most-searched request for this format is “ROFL to MP4”, and it cannot be satisfied by a converter, for a concrete reason: there is no video inside the file to convert. A ROFL holds game commands, so producing an MP4 means the League engine has to render the match to actual frames first. The only workable route is to play the replay in the client and screen-record the window with capture software such as OBS Studio, NVIDIA ShadowPlay or the Windows Game Bar, which encodes the rendered gameplay into H.264 in a real MP4 or MKV container. Any website or download promising a direct ROFL-to-MP4 conversion is misrepresenting what the file is, and around game-file searches such “converters” and “viewers” are a common vehicle for bundled adware. The file itself is safe, since it is only ever interpreted by the official client, but the third-party tools that claim to unlock it are the actual risk.

References