Initializing... drag & drop files here
Supports: GIF
This turns a GIF — animated or static — into a .ts file: an MPEG-2 Transport Stream (ISO/IEC 13818-1, published jointly as ITU-T H.222.0), the container built for broadcast and streaming rather than for storage. The video inside is H.264 by default, the same codec transport-stream segments carry in an HLS ladder, so the output drops straight into digital-TV, IPTV, set-top-box and segmenter tooling that expects a transport stream. If the clip is headed for a browser, a phone or a chat app, that packetised resilience buys you nothing — use GIF to MP4 instead.
.ts. Files upload over an encrypted connection, are processed on our servers and are deleted automatically after a few hours — no sign-up, no watermark, never shared.| Property | GIF (source) | TS (Transport Stream) | MP4 |
|---|---|---|---|
| Standard | GIF87a in 1987; GIF89a in 1989 | ISO/IEC 13818-1 / ITU-T H.222.0 | ISO/IEC 14496-14 |
| Container role | Image file with frames | Transport for broadcast and streaming | General-purpose storage and delivery |
| Structure | LZW-coded frames | Fixed 188-byte packets | Boxes with a global header and index |
| Joinable mid-stream | No | Yes — a decoder can latch on partway through | No, the header is needed first |
| Default video codec here | Not applicable | H.264 | H.264 |
| Colour | 256 per frame, palettised | 8-bit YUV, full colour | 8-bit YUV, full colour |
| Audio from a GIF source | None | None — the output is silent | None — the output is silent |
| Plays inline in a browser | Yes, as an <img> |
No | Yes, via <video> |
| Best at | Reactions, pixel art, web loops | HLS, IPTV, broadcast chains | Web, social, messaging |
A transport stream exists to survive lossy delivery: it is chopped into fixed 188-byte packets, can carry several programs at once, and repeats enough signalling that a receiver tuning in halfway through can start decoding. That is why broadcast and HLS pipelines use it and why it is a poor choice for a file you simply want to send someone.
Our encoder maps the Quality Preset to a codec-specific CRF rather than a fixed bitrate, and it shifts that CRF with the output size — a small GIF-sized frame gets a lower CRF (better quality) than a 1080p frame, clamped to two steps in either direction.
| Codec choice | "Very High" maps to | Where it fits |
|---|---|---|
| H.264 (default) | CRF 18 at 1080p | HLS segments, IPTV, set-top boxes, capture chains — the safe answer |
| H.265 | CRF 17 | Newer OTT and HLS chains that have moved to HEVC |
| MPEG-2 | No CRF — a bitrate scaled from the source | DVB and ATSC broadcast gear, DVD-era hardware |
| MPEG-1, MPEG-4, Xvid, DivX | Bitrate-based, no CRF | Legacy encoders only; transport-stream players and hardware decoders rarely expect these, so pick one only if a device asks for it |
Yes. Every frame of the GIF is decoded and encoded in order as real video inside the transport stream, so a looping GIF becomes a clip of the same length rather than one held frame. The "Image Duration", "Merge strategy" and "Trim" controls that appear on still-image-to-video tools are hidden for GIF sources, because the GIF already carries its own per-frame delays and we use those directly.
No. A GIF has no audio stream, so there is nothing to carry over and the output is silent by nature rather than muted. The Audio Codec list still renders because it belongs to the shared video option group, but there is no source audio for it to encode. Mux an audio track in later if your workflow needs one.
Video codecs have no alpha channel, so transparent pixels are filled with the Background Color before encoding. It defaults to White for GIF sources, with the full list of named colours in the dropdown including Black. The same colour fills any letterbox bars if you rescale to a different aspect ratio.
Only when the receiving end specifically ingests transport streams — digital television, IPTV set-top boxes, live broadcast chains, or segmenter tooling. HTTP Live Streaming originally shipped MPEG-2 Transport Stream segments carrying H.264, which is exactly what this page produces by default, though newer HLS deployments can also use fragmented MP4 segments. For the web, phones or social, MP4 is smaller to deliver and plays inline.
H.264 unless something tells you otherwise; it is the default and the broadest fit for transport-stream pipelines. H.265 halves the bitrate for chains that have moved to HEVC. MPEG-2 is the right pick for older broadcast and capture hardware. The remaining MPEG-1, MPEG-4, Xvid and DivX entries are legacy encoders that most transport-stream decoders do not expect — choose them only when a specific device requires it.
No. The output can match the source but never exceed it: your GIF is already capped at 256 colours per frame at whatever resolution and timing it was saved with. H.264 removes the palette banding, so gradients often look cleaner, but no preset invents detail the GIF never captured, and upscaling only enlarges the pixels that are already there.
No, and it cannot be. We always decode the GIF to raw frames and re-encode them — there is no passthrough or remux path from an image format into a video stream — so a lossy codec discards some detail. Selecting "Highest" gets as close to visually lossless as CRF encoding goes.
.ts file play in my browser or on my phone?Generally not. Browsers do not play a raw transport stream in a <video> tag, and most phones need a third-party player such as VLC or mpv. Broadcast and streaming infrastructure is where a .ts belongs. If you already have one and need something portable, TS to MP4 rewraps and re-encodes it into a web-friendly file.
Yes. Queue them all and they convert with the same codec, preset, background colour and resolution settings, each producing its own .ts. There is no join step here, so combining several streams into one program is a job for your segmenter or muxer.