One frame, one button, one file

There are three situations where a moving picture does the job that a paragraph cannot. Writing a tutorial and needing to show the sequence of clicks. Reporting a bug and needing to show the moment it goes wrong. Demonstrating an animation and needing the timing to be visible. In all three, a short animation is worth ten screenshots, and in all three the usual tools turn a thirty-second task into a small project: create a document, set a region, record, then open the timeline, trim, and export to a format that will actually be accepted.

LICEcap removes every step that is not the recording. A frame appears on the screen that you drag and resize like a window, position it over the area of interest, press record, and when you stop, the file on disk is already a usable animation. There is no project, no timeline, no export dialog. The frame rate is adjustable, the frame count and elapsed time are visible while recording, and the frame can be moved mid-recording, which quietly solves the specific embarrassment of discovering two seconds in that the captured area is the wrong size.

A small program with a steady foundation

The installer is a few hundred kilobytes, and the program asks nothing of the machine, which is why it still works on hardware that modern recorders consider obsolete. Besides the animation format everyone accepts, it writes its own high-compression format, which is friendlier for longer captures where the file size would otherwise become the problem rather than the content.

It comes from the same small studio behind a well-known audio workstation, and that origin explains its character: stable for years, deliberate about what it does, and uninterested in adding features it does not need. Updates are infrequent, and that is not a warning. The function set was complete a long time ago, so there is nothing to wait for. It covers Windows and macOS, and it is free to use.

Its virtue is being exactly enough: no editing, no filters, only the capture step made smooth. A tool with clearly drawn boundaries is a tool you can use without a mental overhead.

Getting a good result from a small tool

Ten to fifteen frames per second is plenty for demonstrating an interface, and going higher only makes the file larger without making the action clearer. The eye does not need sixty frames to understand a menu opening. Set the rate deliberately rather than leaving it at whatever the default happens to be, because file size is the constraint most often hit when sharing the result.

Trim the beginning and end afterwards with whatever image tool you already have, rather than asking this program to grow an editor it deliberately does not have. The first second of a capture is almost always the moment where you moved the mouse into position, and the last second is you reaching for the stop button; both are noise.

For a complex tutorial that needs annotations, arrows and voice, a professional recorder is the right answer and this is not. For attaching an image to an issue, illustrating a document, or showing a colleague what a menu looks like, it is the small pair of scissors that happens to be on the desk, and it will keep being on the desk for years because nobody has to maintain it.