GIF to Live Photo without leaving the tab

Someone on the marketing channel drops a looping GIF and asks if we can use it as an iPhone Lock Screen. Half the team is on Linux. The other half has never heard of a .livp file. Nobody wants to install another "GIF to Live Photo" Mac app for a one-off wallpaper request.

For a while my path was: find a cloud converter, upload the GIF, download something that might open on iPhone, AirDrop it, discover Photos rejected the package, try again. That was fine for memes. It was wrong the moment the GIF included unreleased UI or a client brand mark.

These days I convert GIF → Live Photo in the browser, preview the loop in the same tab, download a .livp, and only then AirDrop to the phone. No desktop app. No account. No "we delete uploads in 24h" promise I can't verify.

Why this shows up in frontend work

Live Photos are an Apple Photos format: a still JPEG paired with a short H.264 movie, tied together with a content identifier and a still-image-time track. Designers and PMs want them for:

• Lock Screen / wallpaper motion from an existing GIF
• iMessage shares that feel more "Photos" than "Giphy"
• Reaction loops that should press-and-hold like a real Live Photo
• Demo assets for iOS marketing that started life as a Slack GIF

It's almost never a product feature. It's a format bridge between "we already have a GIF" and "Photos will accept it." Wiring FFmpeg into the app for that is usually overkill.

The upload tax (again)

Most "GIF to Live Photo online" tools still POST the bytes. The UI looks local; the Network panel says otherwise. For anything from a private beta, client work, or staging UI, that's the wrong default.

What I want for this job:

1. Frames stay in the tab — decode → encode locally (WASM / FFmpeg-in-browser), then download
2. Preview before download — so I catch a broken loop before AirDrop
3. No signup before the download button works
4. A real .livp Photos can import — not a lone MOV with "hope for the best" metadata
5. Survives Offline in DevTools after the first WASM load

If convert dies the moment I flip Offline (after the runtime is cached), I close the tab.

A quick check before I trust the tool

Same habit as with HEIC converters:

// After dropping a redacted sample GIF and clicking Convert:
performance.getEntriesByType("resource")
  .filter((r) =>
    r.initiatorType === "fetch" ||
    r.initiatorType === "xmlhttprequest"
  )
  .map((r) => r.name);

Expect a one-time fetch for the WASM/FFmpeg core. Do not expect a POST of the GIF itself to some api.* host. Then flip Offline and convert again — if export still works, the bytes stayed local.

Always use a redacted sample first (no faces, no product chrome). Never validate the trust model with the real asset.

The loop I reuse

1. Redacted sample GIF first
2. Open a browser-local GIF → Live Photo tool
3. Drop → convert → preview the loop in-tab
4. Download .livp
5. AirDrop to iPhone → open from Files → save to Photos
6. Confirm press-and-hold motion + still look right
7. Close the tab, then run the real GIF

Under the hood the good tools encode frames to H.264, pair a JPEG still, stamp Apple's content identifier / still-image-time metadata, and zip that into .livp. You can roll your own with ffmpeg.wasm if this is a weekly pipeline. For "someone Slack'd a wallpaper GIF," a solid tab beats a side project.

When I need that tab fast, I've used Uwarp's GIF to Live Photo tool — drop the GIF, convert in the browser, preview, download .livp. Worth trying when you don't want an App Store install or another upload site in the critical path.

Tips that actually matter for wallpaper GIFs

• Keep it short. Live Photos only play a few seconds; trim long GIFs first.
• Prefer clean loops. A hard cut mid-motion looks worse after H.264 than a GIF that already looped cleanly.
• Portrait or square for Lock Screen. Wide landscape memes waste the phone chrome.
• Finish on device. AirDrop the .livp and open it on iPhone so Photos can register the paired still + movie. Don't expect Linux to "preview" a Live Photo the way Photos does.

When you should put this in the product

Sometimes the one-off habit is wrong:

• Users upload GIFs and your iOS app must emit Live Photos at the API boundary
• You're building a creator tool where Live Photo export is a checked feature
• You need batch conversion with consistent CRF / duration caps

Then own the encode path (server or WASM), test the metadata, and don't paper over failures with "please use this random website." That's product work.

For internal wallpaper requests and marketing one-offs? Keep it out of the codebase. Convert once in a tab, AirDrop, move on.

DX note: agents and media uploads

If an agent is helping with asset pipelines, constrain it: browser-local convert or local FFmpeg; no third-party upload of product or client assets. Agents default to whichever cloud converter snippet ranks first — which is often the upload path you're trying to avoid. Paste the policy into the prompt the same way you'd paste a lint rule.

What I stopped doing

• Installing a one-purpose Mac app for a single Lock Screen request
• Uploading unreleased UI GIFs to the first Google result for "gif to live photo"
• Shipping a lone MOV and hoping Photos treats it as a Live Photo
• Asking the agent to "just host the GIF somewhere and convert it"

GIF → Live Photo is a packaging problem, not a collaboration problem. Fix it in the browser, verify on the phone, close the tab. If you want a concrete starting point, the GIF → Live Photo page on Uwarp is the one I've reached for when the team is mostly on Linux and nobody wants another desktop converter.