EasyGIF

Guides · Privacy

How to check whether a GIF maker uploads your files

Many online GIF makers send your photos and videos to a server. Here's how to see for yourself, in two minutes with your browser's developer tools, whether a tool uploads anything.

By Li Jiang · Published · 4 min read
Tested: Network check run in Chrome on EasyGIF's live site with 7.4 MB of images; offline test run with the web server shut down; Firefox steps from Mozilla's documentation

"Free online GIF maker" can mean two very different things. Some tools send your photos or video to their server, make the GIF there, and send it back. Others, including EasyGIF, do all the work inside your browser, and your files never leave your device. Both look the same from the outside, and privacy policies aren't always clear about which kind you're using.

You don't have to take anyone's word for it. Every desktop browser can show you each request a page makes, including how much data it sends. This guide shows how to check any GIF maker in about two minutes.

Why it matters

The files people turn into GIFs are often personal: clips of children, screen recordings showing email or company dashboards, photos from inside a home. Once a file is uploaded, it's subject to the service's storage, retention, and security, none of which you can see. A tool that processes locally has nothing to store, leak, or hand over.

What to look for

An upload is a network request whose size is at least the size of your file. A 20 MB video upload is a 20 MB request, and a GIF made on a server comes back as a download of roughly the GIF's size. Those are hard to miss in the Network panel. Small requests for ads, analytics, or fonts are normal on most sites and don't carry your file.

Step-by-step in Chrome or Edge

  1. Open the GIF maker you want to test.
  2. Open DevTools: F12, or Cmd + Option + I on a Mac, or right-click the page and choose Inspect.
  3. Click the Network tab. Turn on Preserve log, then click the clear button (the circle with a line through it) to start with an empty list.
  4. Click the Size column header twice to sort the largest requests to the top.
  5. Now use the tool as you normally would: add a large file, ideally a video of tens of megabytes, edit it, and create the GIF.
  6. Look at the list. If a request near the top has a size close to your file's size, or a method of POST or PUT to the tool's own domain sent just after you added the file, the tool uploaded it. If the largest requests are a few kilobytes of scripts, ads, or analytics, nothing was uploaded.

In Firefox the steps are the same: open the Network panel with F12, enable Persist Logs in its settings menu, and sort by Transferred size.

The offline test

A second check is even simpler, because a tool that needs a server stops working without a connection:

  1. Open the GIF maker and make one GIF the normal way. Some tools, EasyGIF included, download parts of the encoder only when they're first needed, so do one run online first.
  2. Disconnect from the internet: turn off Wi-Fi, or in Chrome DevTools set the Network throttling menu from "No throttling" to Offline.
  3. Add a new file and create another GIF.

If the GIF still gets made and downloaded, the processing is happening on your device. If the tool shows an upload error or spins forever, it depends on a server.

What you'll see on EasyGIF

On EasyGIF, the Network panel shows the page's own scripts and styles, Google's ad and consent scripts, and Google Analytics. Google's consent and ad-quality scripts also send small requests of their own every so often, including POSTs to google.com addresses; they're a few hundred bytes each and go out whether or not you've added a file.

When we ran the steps above, we added four images totaling 7.4 MB and created a GIF. No request came anywhere near that size, and nothing at all was sent to easygif.app. The only request the GIF maker itself made was for its encoder script (two small files, about 11 KB together) when we clicked Create GIF; after the first time, the browser serves it from its cache. For the offline test, we made one GIF, shut the web server down completely, then added a new image and created another GIF: it worked.

The rest of the work happens with standard browser features:

  • Reading your files: the File API gives the page access to the file you choose, in memory, without sending it anywhere.
  • Decoding: images are decoded by the browser's own image decoder; animated GIFs are split into frames the same way; videos play from your disk in a hidden video element, and frames are copied from it onto a canvas.
  • Encoding: the GIF is built in a Web Worker, a background thread in your browser, using the open-source gifenc encoder.
  • Downloading: the finished GIF is handed to your browser's download manager as a local file, not fetched from a server.

What these checks can't tell you

The Network panel shows what a page does while you watch. It can't prove what a tool might do in a different version, a different browser, or after an update. A tool that processes locally today could change. Re-running the check now and then takes two minutes. It also doesn't cover the rest of your device: browser extensions, for example, can see pages you visit, so use a clean browser profile for anything sensitive.

For a quick answer, though, the two tests above are reliable: large outgoing requests mean uploads, and a tool that keeps working offline isn't uploading anything.

Try it on your own files

Free, no sign-up, and made on your device. Nothing is uploaded.

Open the GIF creator

Sources (last checked October 10, 2026)

Spotted something out of date? Please let us know.

Related guides