WRP: a web rendering proxy for vintage browsers

A browser inside a browser

WRP is a browser-in-browser proxy server that allows you to use historical or vintage web browsers on the modern web. The demonstration in the README is Internet Explorer 1.5 opening Gmail, which is the kind of image that tells you the whole project in one frame.

The mechanism is straightforward once you see it. A modern machine runs WRP, WRP drives a headless Chrome, and the vintage browser talks to WRP rather than to the internet. What the vintage browser receives depends on the mode, and both modes are ways of throwing away the parts of a modern page that the old browser cannot handle.

The project names its requirements plainly, and the first one is the important one. You download a WRP binary and run it on a machine that will become your WRP gateway or server, and it should be modern hardware and OS. Google Chrome, Chromium or Brave Browser has to be preinstalled. And the README is explicit that you should not run WRP on an old machine like Windows XP or 98.

That is the whole architecture in one sentence: the old computer is the display, the new computer is the browser, and WRP is the translation layer between them. The repository is a Go module, and the code reflects that split, with the rendering driven through chromedp, the Chrome DevTools Protocol client.

The release history shows the project being kept current with the browsers it drives. Version 4.10.0 in March 2026 brought the real proxy mode back, 4.10.2 in April 2026 added support for downloads, and 4.10.3 added automatic browser detection, so the user no longer has to point the server at a specific Chrome binary.

Two ways in, two ways out

The modes of operation are split along two axes, and the README keeps them separate.

On the access side there is the browser-in-browser mode, where you navigate to the address of WRP and use the built-in web form to browse the web. Then there is the HTTP proxy mode, which offers a smoother experience but is also more limited, and is only semi compatible with https.

On the rendering side there is the ISMAP graphical mode, which renders the web page into a GIF, PNG or JPG image with a clickable image map, and the simple HTML mode, which converts pages into simplified HTML for old browsers.

The README says the two are used differently, and the distinction is worth understanding. ISMAP mode will be better for flashy modern web, and simple HTML mode will be better for reading articles or documentation.

That is the real trade-off in the project. The image map mode preserves the visual design exactly, because it is a picture of the real page, and everything interactive becomes a click on a coordinate. The simple HTML mode throws the design away and keeps the content, so text reflows and links work, but you get a document rather than a website.

For reading documentation from a machine with a small monochrome screen, the simple HTML mode is the one that makes sense. For a period machine with a colour display that you want to look at the real thing, the image map mode is the one that matters.

The flags are the configuration

The proxy mode has no web interface at all, which is why the flags carry the whole configuration surface.

-l   listen address:port (default :8080)
-m   mode, either ismap (graphical) or html
-t   image type gif, png or jpg (default gif)
-g   image geometry, WxHxC, height can be 0 for unlimited (default 1152x600x216)
      C (number of colors) is only used for GIF
-q   Jpeg image quality, default 75%
-h   headless mode, hide browser window on the server (default true)
-n   do not free maps and images after use (default false)
-ui  html template file (default "wrp.html")
-ua  user agent, override the default "headless" agent (only for ismap mode)
-s   delay/sleep after page is rendered before screenshot is taken (default 2s)
-b   browser executable path (e.g., for Brave Browser)
-profile  Chrome user-data dir, persists cookies/logins and the session between runs

Several of these deserve a note.

The -profile flag is the one that changes what the tool is. Pointing it at a Chrome user data directory persists cookies and logins and the session between runs, which is the difference between a proxy you have to log in to every time and one that behaves like a browser you already use.

The -ua flag exists because the default user agent is the string headless, and plenty of sites treat that differently from a real browser. The -b flag points at a specific browser executable, which pairs with the 4.10.3 release that detects the browser automatically. The -s flag is the delay between rendering and screenshot, and it is the knob you turn when a page renders slowly.

The -g geometry is width, height and colours, and a height of 0 means unlimited.

The tall image trick, and why the README warns about it

The image map mode is where the interesting engineering is, and the tall image option is the part with a warning attached.

Normally the image is sized to fit the old browser, and you scroll the page by clicking the scroll bar rendered inside the image on the right. WRP also allows a single tall image without the vertical scrollbar, using client side scrolling instead, and you enable it by setting the height to 0, or with the flag -g 1152x0x216.

The README says this should not be used with old and low spec clients, because such tall images will be very large, take a lot of memory and a long time to process, especially for GIFs. The simple HTML mode repeats the same warning, calling the zero size experimental, buggy, and something to use with PNG and lots of memory on the client side.

The advice about image types is more actionable. The default is a GIF, described as an ultra fast, optimised, parallel encoded GIF type, and the README says that if your browser supports it you should prefer PNG, because PNG is much faster whereas GIF and JPG require a lot of additional processing on both client and server to compress and uncompress.

That sounds backwards, since PNG is normally the bigger format, and the resolution is that the cost here is the encoding work, not the file size. A modern server can hand out a PNG almost for free, while a GIF has to be encoded with a palette, and the palette is the other constraint. GIFs are encoded by default with 216 colours in a web safe palette, using an algorithm optimised mostly for text, which is why the README says the colours are rather wonky, and suggests switching to 256 colour mode for better colour representation.

A UI made of single letter keys

The web interface is a form with short keys, and the README lists all of them, which is unusual documentation for a tool this size and very useful.

Go navigates to the URL or performs the search. Bk is history back. St stops and also re-captures the screenshot without refreshing the page, which is the fix for a page that had not finished rendering or that updates periodically. Re reloads the page and re-captures. Up and Dn are page up and page down. W is the width in pixels, H the height, Z zooms or scales, M switches between the ISMAP and simple HTML modes, T sets the image type, and C sets the number of colours for GIF images only.

Then the input ones. K is a keystroke input box, where you type some letters and click Go and they are typed into the remote browser, with additional buttons for backspace, return and the arrow keys. The README is explicit that you should not use the client browser's own history back and should use the Bk button instead.

The UI itself is customisable. WRP supports customising its own UI using an HTML template file, and the instructions are to download wrp.html, place it in the same directory as the wrp binary and edit it, which is the -ui flag with a default of wrp.html.

The simple HTML mode has its own smaller set of controls: you select the image type as PNG, GIF or JPG, each individual image from the original web site is converted to the selected format, and you type the maximum image size in pixels.

Four deployment routes, and one of them will not work

There is a Docker image, and it is the shortest path.

$ docker run -d --rm -p 8080:8080 tenox7/wrp:latest

Beyond that there are three cloud recipes, and the README is refreshingly blunt about the limitation of the last one.

On AWS App Runner you upload the Docker image to ECR and create a service from the console or the CLI, with a create-service command that sets the image configuration port, a CPU of 1024, memory of 2048 and an instance role, and auto deployments enabled.

On Azure Container Instances the command creates a container from the same image with one CPU, two gigabytes of memory, port 80 and a command line that sets the listen address, the PNG image type and a tall image geometry.

On Google Cloud Run the deploy command sets the platform to managed, the image, two gigabytes of memory and the same image type and geometry arguments. And then the caveat: Google Cloud Run forces you to use HTTPS, which likely will not work with old browsers.

That is the one constraint that matters for a project like this, and it is a good illustration of how much of the value depends on the client being able to speak plain HTTP to the proxy.

The Go build is equally portable, with a Makefile that cross compiles for Linux, FreeBSD, OpenBSD, macOS on both architectures, Windows and Linux on ARM, and a release target that drives GoReleaser. The container image is built in two stages from a Go builder on top of the chromedp headless shell image, with the binary compiled statically and the entrypoint set to it.

Editorial conclusion

WRP fits a person with a period computer who still wants the modern web, and who can put a modern Linux or Windows machine next to it to run the server. It does not fit a team that needs a general purpose proxy, since the whole point is to transform pages for clients that cannot handle them, and it does not fit a deployment where the traffic must stay encrypted end to end from the browser, because the proxy has to be able to read and rewrite the pages. Verify three things before you set it up: that the port is reachable from the old machine and the firewall allows it, that you pick the render mode for your content rather than by default, since the image map mode is for visual sites and the simplified HTML mode is for reading articles, and that you leave the default image type alone unless you have a reason, because the default GIF encoding is the fast path and PNG is only better when the client can decode it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tenox7/wrp on GitHub