GIF Combiner

This tool provides both parallel and sequential modes, with Chapters 1 through 6 below describing the parallel mode specifications.

The sequential mode plays each selected GIF once in list order and stitches them into a single output, calculating total duration from original frame delays without manual FPS or duration settings.

Original loop counts are not inherited; instead, the final combined GIF loops continuously as a whole. Processing is limited to a maximum of 15 seconds, 300 frames, and 50 million total processed pixels.

This tool draws each selected media source into its assigned grid cell in listed order, moving from left to right and then down to the next row.

As the media plays, canvas frames are sequentially captured and encoded directly in your browser into an animated GIF or video file.

Original audio tracks and embedded metadata, such as timestamps or device information, are not included in the exported file.

You can upload up to 16 media files of at most 25 MiB each. The dimensions of each asset must not exceed 4096 pixels on any side.

A strict limit is enforced to keep estimated decompression memory across browser assets within 100 MiB. This 100 MiB figure is a conservative estimate derived from GIF patch data, composited frames, and RGBA pixel allocations for single image or video frames, rather than a strict guarantee of total browser memory consumption.

For GIF files specifically, the tool uses gifuct-js to parse and decompress binaries, interpreting logical screen dimensions (width and height) and per-frame placement instructions (such as disposal methods 2 and 3) to composite frames for display.

Note that this input composition method does not guarantee that the exported GIF will feature transparent backgrounds. During actual export, the background is filled with a solid color or a time-varying rainbow gradient.

Furthermore, loop metadata present in input GIFs is ignored; instead, frames repeat continuously for the duration chosen in the export settings.

Hidden canvas compositing reconstructs differential frame updates, though files with unique inter-frame optimizations might not render identically to their original authoring software.

The layout of the composite canvas is determined by configuring rows and columns from 1 to 4 each. Attempting to place more media assets than available grid cells (rows × columns) triggers an export validation error, requiring you to expand the grid or remove extra items.

Output resolution can be adjusted between 64 and 1280 pixels per side, provided total canvas area does not exceed 1,000,000 pixels.

For instance, setting 1280×1280 pixels equals 1,638,400 pixels and will fail validation. Preset buttons for square (1:1), landscape (16:9), and portrait (9:16) facilitate entering standard dimensions while preserving aspect ratios.

Cell gap and outer canvas padding can be adjusted between 0 and 40 px, provided cell dimensions remain greater than zero. The background supports hexadecimal colors via color picker or an animated rainbow gradient.

Fitting within each cell offers three modes: Contain to fit the entire image within the cell while preserving aspect ratio (leaving letterbox margins), Cover to fill the cell and crop overflows, or Stretch to adapt dimensions directly to cell borders.

This allows consistent grid presentation across varied asset ratios.

Playback duration and frame rate (FPS) govern output quality, file size, and browser processing load. Available export durations are 1, 2, 3, 5, 7, 10, or 15 seconds, with selectable frame rates of 10, 12, 15, 20, 24, or 30 FPS.

Canvas rendering proceeds until the selected duration is reached, stopping automatically regardless of source media length. Even when preview playback is paused, exporting GIF or video always reconstructs frames starting from time 0.

The seekVideoFrame routine resolves immediately if the target timestamp matches the current playback position and data is already available.

For different timestamps, it waits for seeked or loadeddata events, timing out with an error if seeking exceeds 10 seconds. This seeking logic captures video frames during GIF rendering, whereas video export plays media in real time after seeking to the start.

During file loading and export execution (indicated by isExporting or isLoading state), layout and timing controls as well as file management are disabled to prevent state conflicts.

A sample GIF button lets you test functionality without your own media, and active object URLs are managed to prevent premature revocation.

When exporting as an animated GIF (.gif), canvas frames are encoded via the gifenc library. This process quantizes RGBA pixel data for each frame into a palette of up to 256 colors.

GIF exports enforce strict thresholds: total frame count cannot exceed 300 frames, and total processed pixel volume (width × height × total frames) cannot exceed 50,000,000 pixels.

Exceeding these limits raises an export validation error, requiring reductions in dimensions, duration, or FPS. Quantization can reduce smooth color gradients and cause visible banding.

Additionally, GIF specifications mandate delays expressed in hundredths of a second (10 ms increments). When requested frame intervals at a given FPS do not align with 10 ms multiples, delay rounding can cause subtle differences in playback speed relative to real time.

Because rendering, capturing, and quantizing each frame is computationally intensive, processing may take dozens of seconds depending on resolution and length.

A progress percentage bar tracks this encoding process.

When video (.mp4 or .webm) is selected, the tool captures a canvas media stream using captureStream and records it in real time via MediaRecorder.

Availability depends on browser and OS capabilities, and MP4 (H.264) encoding is not universally supported. At the start of export, MediaRecorder.isTypeSupported checks browser compatibility; if the requested format is unavailable, the recorder falls back automatically to supported WebM codecs (such as VP9 or VP8).

The exported file extension is adjusted to match the actual MIME type, and when MP4 falls back to WebM, a completion message alerts the user.

Video recording runs as silent real-time capture, meaning a 15-second video takes at least 15 seconds to record plus setup and finalization time.

Downloads start automatically from the generated Blob once recording finishes. Backgrounding the browser tab during capture may throttle rendering rates due to browser resource conservation, causing stuttering in the exported video.