Initializing... drag & drop files here
Supports: JPG, JPEG, JFIF
.jfif is an ordinary JPEG — the JPEG File Interchange Format wrapper, the same picture data as a .jpg, just carrying the other conventional extension. .mxf is the Material eXchange Format, the SMPTE ST 377-1 container that Avid, Resolve, station playout servers and broadcast archives use as their working wrapper.
Wanting to put a still into an MXF is a reasonable thing: a slate, an ident, a title card, a photograph for a documentary segment. But MXF is far stricter than a general-purpose container, and the strictest thing about it is timing. MXF only accepts a small, fixed set of broadcast frame rates. A single photograph has no frame rate at all, and the still-image encoder here holds each picture at one frame per second, which is not one of the rates MXF permits. The result is that a lone still does not have a legitimate timing to be wrapped with, and this is not a setting you can adjust — there is no frame-rate control on this page.
This page therefore tells you the reliable way to get a still into a broadcast MXF, which runs through your editing system rather than through a direct conversion. If all you actually wanted was a clip from a photograph, JFIF to MP4 does that in one step and imposes no rate restrictions.
Encoding the same still at a range of frame rates and asking the MXF muxer to wrap it gives a clean split:
| Frame rate | Accepted by MXF |
|---|---|
| 1, 2, 5, 10, 12, 15, 20 fps | Rejected |
| 23.976 fps | Accepted |
| 24 fps | Accepted |
| 25 fps | Accepted |
| 29.97 fps | Accepted |
| 30 fps | Accepted |
| 48 fps | Accepted |
| 50 fps | Accepted |
| 60 fps | Accepted |
That list is not arbitrary. MXF encodes timing as a content-package rate drawn from the standard broadcast family, because the format exists to interchange material between systems that all run at one of those rates. A one-frame-per-second asset is not something a playout server or an editing system has a slot for, and even a container that accepted it would be handing your NLE a file at a rate its timeline cannot conform cleanly.
If instead you already have a finished video at a standard frame rate and only need it wrapped, MP4 to MXF does that conversion here directly.
For reference, since the option panel is visible:
| Control | Behaviour |
|---|---|
| Video Codec | Two entries only — MPEG-2 (pre-selected) and H.264. Broadcast MXF essences such as DNxHD, ProRes and AVC-Intra are not offered |
| GOP structure | Forced to GOP 1, all-intra, for MXF compatibility. That is correct for a broadcast wrapper and it makes files considerably larger than a long-GOP encode |
| Merge strategy | Merge images, or one file per image |
| Image Duration | 1/60s up to 10 seconds per frame; 5 seconds pre-selected. It sets the clip's length, not its frame rate |
| Frame rate | No control exists. Stills are encoded at 1 fps |
| Background Color | White pre-selected; fills the area a photograph does not cover |
| Quality Preset | Seven steps, Highest to Lowest. On MPEG-2 it has nothing to scale from for a still source, since a photograph has no source bitrate |
| Constant Quality | A quantizer from 1 to 31 on MPEG-2, or a rate factor from 16 to 51 on H.264 |
| Video resolution | Keep original pre-selected; Fixed Resolutions, Preset Resolutions and explicit Width x Height also available |
| Audio | No controls — an image source has no audio, so nothing is written |
Note the absence in that list: there is no frame-rate setting, which is exactly the parameter MXF cares most about. That is the crux of the mismatch.
Because MXF is an interchange format for professional video, not a general-purpose wrapper. It stores timing as a content-package rate chosen from the standard broadcast family — 23.976, 24, 25, 29.97, 30, 48, 50 and 60 — so that any system reading the file knows exactly how its content lines up against a timecode. MP4, MKV and QuickTime will happily carry anything, including a one-frame-per-second slideshow, because they are delivery and storage containers rather than production interchange. MXF's strictness is the feature, not a limitation to work around.
Not on this page — no frame-rate control is rendered, and Image Duration is not one in disguise. Image Duration decides how long each still is held on screen; the encoder still runs at one frame per second underneath, so a 5-second setting means five identical frames rather than 125 frames at 25 fps. The place where a still acquires a real frame rate is a timeline, which is why the workflow above runs through an editing system.
JFIF to MP4. MP4 places no restriction on frame rate, so the held-still encode works there without complaint, and the resulting file opens in every editor, browser and player. Drop it onto a timeline and your NLE conforms it to the sequence rate on import. If you need a transport-stream flavour instead — for a playout or IPTV chain — the .ts, .mts and .m2ts targets accept the same held-still encode.
Then this is straightforward, because a real video already carries a frame rate. MP4 to MXF wraps it here directly, and the same applies from the other video sources on the site. Two things to know: the encode is forced to GOP 1, all-intra, for MXF compatibility, which is correct for a broadcast wrapper but produces a substantially larger file than a long-GOP encode; and MXF audio must be at 48 kHz, so a soundtrack at 44.1 kHz needs resampling.
.jfif a separate thing from .jpg anyway?It is not, in any meaningful sense. JFIF is the JPEG File Interchange Format, the conventional wrapper that says how a JPEG's compressed data is laid out in a file along with density and thumbnail information. Both extensions denote the same kind of file, and the .jfif spelling shows up mostly because some browsers and applications save downloaded JPEGs with it. Anything that opens a .jpg opens a .jfif; renaming one to the other changes nothing but the label.
Not on its own, no. A conforming deliverable is expected to carry an essence at a standard rate, usually with an audio track — often silent, but present — and to sit inside a defined operational pattern such as OP1a. A loose file with a photograph in it satisfies none of that even when the wrapping succeeds mechanically. That is the deeper reason the NLE route is the right one: an editing system's MXF export is written against a delivery specification, so what comes out is a file the receiving system was built to accept.
TIFF if the still is a graphic that will be scaled, keyed or colour-managed, because it is lossless, carries full bit depth and is what broadcast graphics workflows have used for decades. PNG if you want lossless with a smaller file and possibly transparency, which every current NLE imports without difficulty. What you should avoid is handing the editor another JPEG: the JFIF already carries one generation of JPEG compression, and re-saving it adds a second for no benefit. Convert once, losslessly, and edit from that.
Yes, and it is worth checking before you build anything around it. A JFIF is a lossy file, so whatever compression artefacts it already contains — blocking in flat areas, ringing around text and hard edges, colour smearing on saturated reds — are baked in and will be visible when the still is held full-screen on a broadcast monitor for several seconds. Held stills are unusually unforgiving that way, because the viewer has time to look. If the picture originated as something better than a JPEG, go back to that original.
It gets fitted, not cropped. A 3:2 photograph placed in a 16:9 raster leaves bars on two sides, and those bars are filled with the Background Color, which is pre-selected as White — rarely what you want in a broadcast context, where black is the convention. Doing this framing on a timeline instead gives you the same result with the advantage of being able to see it, and lets you choose between pillarboxing, cropping and a scaled-and-blurred backdrop.
Whatever you upload travels over an encrypted connection, is processed on our servers, and is deleted automatically after a few hours along with whatever it produced. There is no sign-up, no watermark, and nothing is shared or made public. That applies equally to the still conversions recommended above and to the video conversions — nothing is retained once the window closes.