webp_server_go is a free, open source photo & video editors project written in Go and released under GPL-3.0. It has 2,007 GitHub stars, 188 forks and 3 open issues, and was last pushed 27 hours ago. On this registry it ranks #50 of 69 tracked projects in Photo & Video Editors, with 5 head-to-head comparisons available.

What is webp_server_go?

WebP Server Go is an on-the-fly image conversion proxy for website operators and self-hosters who want their existing JPG, PNG, BMP and SVG assets served as compressed WebP or AVIF without touching the original files.

What it is

WebP Server Go is a server written in Golang that converts images on the fly as they are requested, returning them in WebP or AVIF format with compression applied. The currently supported input formats are JPEG, PNG, BMP, GIF, SVG, HEIC, NEF and WEBP; a GIF is never converted to AVIF because the resulting AVIF image would not be animated. The server is identified by the topics image-optimization, image-processing, pagespeed, serving-images, webp and webp-server, and its documentation lives at https://docs.webp.sh.

The concrete problem it solves is replacing an entire directory of static images with optimized variants one file at a time. When a client requests https://your.website/pics/tsuki.jpg, the server responds with image/webp or image/avif content while the URL itself stays unchanged, so no HTML, markup or asset links need to be edited. Its storage model separates three responsibilities: the pics directory holds original files, exhaust holds converted outputs, and metadata holds source metadata used for cache validation.

Key capabilities

  • Converts requested JPEG, PNG, BMP, GIF, SVG, HEIC, NEF and WEBP sources to WebP or AVIF without altering the original file path.
  • Serves the optimized bytes under the original URL, so https://your.website/pics/tsuki.jpg keeps working after deployment.
  • Maintains a conversion cache in an exhaust directory alongside the originals, with a separate metadata directory used for cache validation.
  • Runs as a Docker container exposing port 3333, with 127.0.0.1:3333:3333 bound on the host in the supplied docker-compose.yml.
  • Accepts a custom config.json mounted into the container at /etc/config.json.
  • Exposes image metadata endpoints documented under /metrics and /hostinfo in the configuration docs.
  • Publishes binaries and container images through GitHub Actions workflows (CI.yaml, release_binary.yaml, release_docker_image.yaml).

Who uses it and how

  • Website operators whose images live under a document root such as /var/www/img.webp.sh/path/tsuki.jpg and who expose them at https://img.webp.sh/path/tsuki.jpg by pointing ./path/to/pics at that root.
  • Self-hosters who place the container on 127.0.0.1:3333 and publish it publicly through a reverse proxy, for example an Nginx proxy_pass http://127.0.0.1:3333/;.
  • Teams that keep converted output and source metadata in dedicated host folders (./exhaust and ./metadata) mapped to /opt/exhaust and /opt/metadata in the container.
  • Administrators who pin a specific configuration by mounting a generated config.json rather than relying on defaults.

Getting started

Run it with Docker as recommended: create a docker-compose.yml using the image webpsh/webp-server-go (or ghcr.io/webp-sh/webp_server_go), mount ./path/to/pics, ./exhaust and ./metadata, then start it with docker-compose up -d.

How it compares

The project sits among general image-optimization and page-speed tooling rather than alongside a specific named competitor in this registry, serving the niche of a dedicated conversion endpoint between a web server and its clients. The README itself warns that running the bare binary instead of the container may run into problems with glibc and dependency libraries, which is why Docker is the recommended path.

When to use it — and when not

A self-hoster must operate the container itself, keep the three mounted directories consistent, and put a reverse proxy in front of the loopback-bound port to make the service public; there is no hosted option described. You should not pick it if you need AVIF output for animated GIFs, since those are deliberately excluded, or if you cannot run Docker, given the documented glibc and dependency complications of the binary. The licence is GPL-3.0, which matters if you intend to redistribute it as part of a combined work.

project readme (upstream, from github) — read inline

CI build docker image Release WebP Server Go Binaries codecov Docker Pulls

Documentation | Website | Blog

This is a Server based on Golang, which allows you to serve WebP images on the fly.

Currently supported image format: JPEG, PNG, BMP, GIF, SVG, HEIC, NEF, WEBP

e.g When you visit https://your.website/pics/tsuki.jpg,it will serve as image/webp/image/avif format without changing the URL.

GIF image will not be converted to AVIF format because the converted AVIF image is not animated.

Usage with Docker(recommended)

We strongly recommend using Docker to run WebP Server Go because running it directly with the binary may encounter issues with glibc and some dependency libraries, which can be quite tricky to resolve.

flowchart LR
client["Client\nGET /some-images/tsuki.jpg"] --> server["WebP Server Go\n:3333"]

subgraph host["Host machine"]
hostPics["/path/to/pics"]
hostExhaust["./exhaust"]
hostMeta["./metadata"]
end

subgraph container["Docker container"]
cPics["/opt/pics (source images)"]
cExhaust["/opt/exhaust (optimized cache)"]
cMeta["/opt/metadata (source metadata)"]
end

hostPics <-- "volume mount" --> cPics
hostExhaust <-- "volume mount" --> cExhaust
hostMeta <-- "volume mount" --> cMeta

server --> cPics
server --> cExhaust
server --> cMeta
server --> response["Return optimized image\n(webp/avif/jxl)"]

This helps separate responsibilities clearly: pics stores original files, exhaust stores converted outputs, and metadata stores source metadata used for cache validation.

Make sure you've got Docker and docker-compose installed, create a directory and create docker-compose.yml file inside it like this:

version: '3'

services:
  webp:
    image: webpsh/webp-server-go
    # image: ghcr.io/webp-sh/webp_server_go
    restart: always
    volumes:
      - ./path/to/pics:/opt/pics
      - ./exhaust:/opt/exhaust
      - ./metadata:/opt/metadata
    ports:
      - 127.0.0.1:3333:3333

Suppose your website and image has the following pattern.

Image Path Website Path
/var/www/img.webp.sh/path/tsuki.jpg https://img.webp.sh/path/tsuki.jpg

Then

  • ./path/to/pics should be changed to /var/www/img.webp.sh
  • ./exhaust is cache folder for output images, by default it will be in exhaust directory alongside with docker-compose.yml file, if you'd like to keep cached images in another folder, you can change ./exhaust to /some/other/path/to/exhaust
  • ./metadata is cache folder for images' metadata, by default it will be in metadata directory alongside with docker-compose.yml file

Start the container using:

docker-compose up -d

Now the server should be running on 127.0.0.1:3333, visiting http://127.0.0.1:3333/path/tsuki.jpg will see the optimized version of /var/www/img.webp.sh/path/tsuki.jpg, you can now add reverse proxy to make it public, for example, let Nginx to proxy_pass http://127.0.0.1:3333/;, and your WebP Server is on-the-fly!

Custom config

If you'd like to use a customized config.json, you can follow the steps in Configuration | WebP Server Documentation to genereate one, and mount it into the container's /etc/config.json, example docker-compose.yml as follows:

version: '3'

services:
  webp:
    image: webpsh/webp-server-go
    # image: ghcr.io/webp-sh/webp_server_go
    restart: always
    volumes:
      - ./path/to/pics:/opt/pics
      - ./path/to/exhaust:/opt/exhaust
      - ./path/to/metadata:/opt/metadata
      - ./config.json:/etc/config.json
    ports:
      - 127.0.0.1:3333:3333

You can refer to Configuration | WebP Server Documentation for more info, such as custom config, AVIF support etc.

Or, if you need some examples, you can refer to Configuration Examples | WebP Server Documentation.

Advanced Usage

If you'd like to use with binary, please consult to Use with Binary(Advanced) | WebP Server Documentation

spoiler alert: you may encounter issues with glibc and some dependency libraries.

For supervisor or detailed Nginx configuration, please read our documentation at https://docs.webp.sh/

WebP Cloud Services

We are currently building a new service called WebP Cloud Services, it now has three parts:

  • Public Service
    • GitHub Avatar/Gravater reverse proxy with WebP optimization, for example, change https://www.gravatar.com/avatar/09eba3a443a7ea91cf818f6b27607d66 to https://gravatar.webp.se/avatar/09eba3a443a7ea91cf818f6b27607d66 for rendering will get a smaller version of gravater, making your website faster
    • Totally free service and currently has a large number of users, this includes, but is not limited to CNX Software, Indienova
  • WebP Cloud
  • Fly
    • We call this service Fly, with the aim of providing a public and free service that users can experience without registering on WebP Cloud. As this is a public service, some limitations compared to WebP Cloud are imposed:
      • Fly supports a maximum original image size of 8MB, while WebP Cloud supports up to 80MB.
      • Fly cache time is 1 day, while WebP Cloud has unlimited time (can be manually cleared at any time).
      • It does not support parameters like blur, sharpen for image processing.
      • And that’s it.

For detailed information, please visit WebP Cloud Services Website or WebP Cloud Services Docs. |

License

WebP Server is under the GPLv3. See the LICENSE file for details.

Security

Please refer to SECURITY.md for more information.

Frequently asked questions

Is webp_server_go free to use?

webp_server_go is open source under the GPL-3.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does webp_server_go do?

Go version of WebP Server. A tool that will serve your JPG/PNG/BMP/SVGs as WebP/AVIF format with compression, on-the-fly.

What is webp_server_go written in?

webp_server_go is primarily written in Go. Its source is publicly available at https://github.com/webp-sh/webp_server_go, and it has 2,007 GitHub stars.