The TinyTask REC File Explained

Record something, stop recording, then press Save on the toolbar.

A standard Windows save dialog opens. Choose a folder, give it a name, and confirm. The window title behind it shows which recording you are working with, which is a useful check once you have several.

Name it for what it does, not for when you made it. You will have several of these before long, and a folder full of files called test1 and test2 helps nobody.

There is one thing worth knowing here. Saving is a separate action from recording. Stopping a recording does not save it. The macro sits in memory, and it is gone when you close the program. If you have just recorded something you want to keep, save it before you do anything else. The full recording workflow is in the how to use TinyTask guide.

Press Open and pick the file.

The dialog filters itself to recording files, so nothing else in the folder gets in your way. Notice the icons on the files in that screenshot. They belong to another program, and the next section explains why.

The recording loads into memory and Play becomes available. From there it behaves exactly as it did when you first recorded it.

Opening a file replaces whatever was in memory. If you have an unsaved recording and you press Open, that unsaved work is gone. There is no warning and no undo.

The program does not register its own file type with Windows. That has one consequence you will meet quickly.

The extension used for recordings is not unique to this program. Other software uses it too, and whichever of those you have installed will have claimed it. On the machine we tested, a media player owned it, so saved macros appeared with that player's icon and Windows offered to open them with it.

Double-click a recording and you will not get a macro. You will get whatever program currently owns that extension, failing to open a file it does not understand.

Always open recordings through the program's own Open button. You can change the association in Windows if you prefer, but there is nothing to point it at, because the program has no file handler of its own. Living with the wrong icon is simpler.

The recording holds what you did and when you did it.

Mouse movement, mouse clicks, key presses, and the gaps between them. The gaps matter as much as the actions do, because they are what makes playback look like a person rather than a burst of instructions.

What it holds is positions, not targets. The file records that you clicked at a point on the screen. It does not record that you clicked a Save button. Nothing in the file knows what any button is called or what any window is for. That single fact explains most of the behaviour on the not working page.

We have not documented the internal format, and we are not going to describe it from guesswork. Other sites state confidently what these files contain and none of them shows any evidence. When we have opened one and looked, this section will say what is actually in there.

There is no editor in this program. No timeline, no list of steps, no way to change a click after the fact.

If a macro is wrong, you record it again. That is the workflow, and for short macros it is genuinely faster than editing would be.

This is the point where a lot of people go looking for the "with editor" download, because the name suggests exactly the missing feature. It is not an editor for this file format. The files labelled that way are a different program from a different company, and they cannot open your recordings. What those downloads actually are is set out in full on the with editor page, with screenshots.

If editing recorded macros is genuinely what you need, that is a real requirement and this is the wrong tool for it. The honest answer is to use something built for it rather than to hunt for a feature that was never here.

You can send the file. Whether it will work for them is a different question.

The person receiving it needs the program, because a recording is not a program. If they do not have it, use the .exe button instead and send them a standalone macro. The compile to EXE page covers that route.

Then there is the harder problem. Your macro clicks fixed screen positions. Their screen is a different size, at a different scaling setting, with windows in different places. A recording that works perfectly on your machine can miss every target on theirs.

Two things reduce the damage. Record with the target window maximised, so its position is at least predictable on any screen. And prefer keyboard steps to mouse clicks wherever the task allows, because keys do not care where anything is.

Keep both, and understand which is which.

The recording is the source. It opens, it plays, and it is the version you can rebuild from.

The compiled file is the output. It runs anywhere, and it cannot be turned back into a recording. Compile as often as you like, but never delete the recording that produced it, because there is no way back.

A few habits that cost nothing.

One folder for all of them. Somewhere in your documents, not the desktop, and not the download folder where things get cleared out.

Descriptive names. What the macro does, in a few words.

Keep the recording next to any compiled version of it. Same folder, same base name. Six months later you will not remember which produced which.

Copy the folder when you move machines. Recordings are your data. Nothing else on your system knows they exist.