MicroWeb: a web browser that fits in a DOS 640K machine
DOS Web browser for 8088 class machines
At a glance
- What is it?
- MicroWeb is a 16-bit real mode browser for DOS that runs on an 8088 with CGA graphics, renders GIF images, has no CSS or JavaScript support, and talks to the network through a DOS packet driver. The interesting engineering is in the memory management and the video mode handling, and the honest limits are in the HTTPS story.
- Who is it for?
- MicroWeb fits a retro computing collector or a preservation project that needs to read the web from hardware with no expansion card, since it runs on an 8088 with 640K of RAM and even a serial port through the EtherSLIP driver.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 115 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A browser for hardware that predates the web
MicroWeb is a web browser for DOS that runs as a 16-bit real mode application and is designed to run on minimal hardware. That single sentence is the whole design brief, and it explains most of the choices in the project.
The minimum requirements are listed without hedging. You need an Intel 8088 or compatible CPU, and a CGA, EGA, VGA or Hercules compatible graphics card. You need a network interface, and the note in parentheses is the interesting part: it is possible to use your machine's serial port with the EtherSLIP driver, which means a machine with no network card at all can still reach the web over a serial link. A mouse is desirable but not 100% required. 640K RAM is desirable but the browser can run with less, and extra memory via XMS or EMS can be used if available, and is recommended for loading heavier web pages and images.
The primary language is C++ and the licence is GPL-2.0, with the COPYING.md file at the root. The default branch is master, the last push to the repository was on 2026-06-30, and the recent releases are v2.1 from 2026-03-12, v2.0 from 2024-04-17 and v0.53 from 2023-07-08.
What this is not is a browser for reading a modern website. It is a browser for a machine that has a 640K address space, which is the constraint every other decision follows from.
What gets rendered, and what gets thrown away
The limitations section in the README is short and worth reading in full, because a modern web is mostly the things this browser discards.
HTTP only, with the HTTPS problem handled separately. Only GIF images are rendered, although PNG and JPEG dimensions are loaded for layout purposes, which is a neat trick: the browser does not decode those formats but still knows how much space they need, so the text flow does not collapse. No CSS or Javascript. Large or complex pages may be truncated if there is not enough RAM available. And the mouse cursor is currently not visible in Hercules mode.
Each of those is a design decision forced by 16-bit real mode rather than an oversight. Decoding a JPEG in 640K of conventional memory is not a matter of effort, it is a matter of arithmetic, so the browser reads the header for the dimensions and renders nothing. The truncation behaviour is the direct consequence of a fixed memory budget with no paging system, and it is why the command line options include a way to disable the image decoders entirely.
The DOM side of the browser is what the Tab and Shift+Tab shortcut cycles through, described as cycling through selectable page elements. Enter follows a link or presses a button. That is the whole interaction model for anything that is not plain text and links.
Fifteen video modes, and a menu that guesses for you
The supported video modes list is the longest part of the README, and it is a good illustration of the period this project targets. You will be asked on startup to select a mode and one will be suggested based on your detected hardware.
The list covers the whole graphics history of the IBM PC compatible: 640x200 monochrome for CGA, 640x200 inverse monochrome for Palmtop CGA, 320x200 4 colours and 320x200 16 colours for composite CGA, 640x200 16 colours and 640x350 in monochrome and 16 colours for EGA, 640x480 in monochrome and 16 colours and 320x200 256 colours for VGA, 720x348 monochrome for Hercules, then 640x400 monochrome for the Olivetti M24, 640x400 monochrome for the Toshiba T3100, 240x128 monochrome for the HP 95LX, and 640x200 16 colours for the Amstrad PC1512.
The last four are the ones that make this project more than a CGA curiosity. A monochrome mode for a specific laptop means a layout that is legible on a small LCD rather than merely on a CRT, and the inverse monochrome mode is for palmtop machines with a flipped screen.
The keyboard table adds a few period details. F2 inverts screen colours in monochrome modes, which the README says is useful for old LCD displays. F3 toggles title bar and status bar visibility, which is a screen real estate decision on a 240x128 panel. F5 reloads, F6 or Ctrl+L focuses the address bar, and Escape exits.
The repository layout supports this: there are CGA.dat, EGA.dat, Default.dat and LowRes.dat files at the top level, which are the mode and palette data, and the source tree has separate CGA, EGA and Hercules implementation files alongside the core sources.
The command line options, and why they are the interesting part
Because there is no room for a settings dialog on a machine with 640K, the configuration surface is the command line, and it is a set of memory and hardware controls rather than the usual browser preferences.
A URL can be passed as an argument to load a specific page on startup, and this can also be a path to a local html file. The options themselves are listed with their effects.
- -invert starts monochrome modes with inverted screen colours, useful for some LCD monitors - -noems disables EMS memory usage - -noxms disables XMS memory usage - -noimages disables the image decoders, useful for very low memory setups - -useswap enables an experimental disk swapping mode to increase available memory - -video=# skips the video mode selection menu and chooses a mode ahead of time
The example in the README combines a URL with a memory flag, given as `MICROWEB -noems http://68k.news`, which will load the 68k.news website on startup but disable the EMS routines.
The -noems option is the one to understand first. EMS is the expanded memory specification, the bank-switched memory above 640K that a 386 or later can address, and using it is how a real-mode program gets more working space than the base 640K. Turning it off is what you do when the machine's EMS driver is absent or unreliable, which is a common situation on real hardware. The -useswap option is the opposite trade, paging to disk, and the README marks it as experimental, which is a fair warning for something that changes the performance characteristics of the whole browser.
The -video=# option exists because the startup mode menu is a modal dialog, and on a machine with no keyboard input device worth the name that is a problem. The example given is -video=a.
The -noimages flag is the memory emergency valve. If a page will not fit, dropping the image decoders entirely is the difference between a readable text rendering and a hang.
No TLS, and the two workarounds the README offers
TLS encryption is currently not supported, which means that only HTTP servers can be accessed directly. The README then gives two options for HTTPS sites, and both are honest about what they are.
The first is a proxy server such as retro-proxy, which converts HTTPS to HTTP. You configure it by setting the HTTP_PROXY environment variable before running MicroWeb, as in `SET HTTP_PROXY=192.168.0.50:8000`.
The second is the FrogFind! web service, which gives a stripped down version of a site, and the README notes that if MicroWeb is redirected to an HTTPS site it will generate a FrogFind link for convenience. In other words, the browser detects that it has been sent somewhere it cannot follow and offers you a link to a rendering service instead.
Neither of these is a TLS implementation, and it is worth being clear about what that means. A translating proxy holds the TLS session on the other side of the connection, so the browser's traffic to the proxy is plain HTTP and the trust boundary sits at the proxy. The FrogFind route is different in kind: the site is fetched by someone else's server and rendered without scripts or styles, which is a different document than the one the browser would have received.
The core issue is a hard one. TLS in 16-bit real mode means either a hand-written implementation with its own cipher and certificate handling, or a library that does not fit in the memory budget. The project has chosen not to spend that budget, and for a browser whose purpose is reaching period content, that is a defensible line rather than a bug. It does mean a MicroWeb install in 2026 will not load most of the web, and the 68k.news site in the README's own example is a good sign of the kind of site it suits.
The network stack, the build, and the floppy images
MicroWeb uses Michael Brutman's mTCP networking library for the network stack, and you will need a DOS packet driver relevant to your network interface. The README links to Brutman's DOS networking documentation for the details of how that is configured.
The build is OpenWatcom. You will need the OpenWatcom 1.9 C++ compiler, and you use OpenWatcom's wmake to build the makefile in the project/DOS folder. Currently only builds in a Windows environment.
That last sentence is a real constraint for anyone who wants to build from source. The Makefile at the root shows why: the compiler is wpp, the linker is wlink, and the link line ends with system dos, which is the OpenWatcom directive for producing a 16-bit DOS executable. The memory model flag is -ml, the small model, and the CFLAGS include -bt=DOS for a DOS executable, -zq and -0 for size optimisation. The link step pulls in the mTCP object files alongside the browser's own objects, which come from App, Parser, Render, Tags, Platform, CGA, EGA, Hercules, TextMode, Font, Interfac, DOSInput, DOSNet and Page. The build directory is obj, and the output is MicroWeb.exe.
The networking library is compiled with its own options, and the Makefile includes custom rules that route .cpp and .asm files in the mTCP library directory through the right compiler, with .asm files handled by the wasm assembler, which is how the low-level packet and interrupt code gets built.
For running it, the getting started section points at the releases page, which includes a pre-built binary. There are also FreeDOS boot disk images for 360K and 720K floppies, configured to work with a NE2000 network adapter, and these can be used in an emulator such as PCem. That is the practical route for anyone who does not own an 8088 with a network card, and the 360K image is worth noting, because a machine with only 360K of conventional memory is exactly the case the -noimages and -noems flags exist for.
Where MicroWeb is the wrong tool
Three cases point elsewhere. The first is a machine that needs to reach a modern site over HTTPS. Since TLS is not supported, the answer is a proxy or a stripped-down rendering service, and either of those changes what you are actually looking at. A period-appropriate browser with a TLS stack is a different project, and for a 1980s machine that wants the 1990s web rather than the 2020s one, a dedicated 1990s browser is the tool that has already solved this.
The second is a user who needs modern pages to render. No CSS and no JavaScript means a large part of the contemporary web is text-only or missing, and the image support stops at GIF. The output is a document, not a page.
The third is a developer who wants to build on the code. The build requires OpenWatcom 1.9 on Windows, the project has no CMake or Make-based build outside the OpenWatcom toolchain, and the browser is a single 16-bit real mode executable with a DOS-specific platform layer. The source is readable C++ with the modules separated cleanly, Parser, Render, Tags, Page, Platform, but it is not a codebase that drops into a modern toolchain.
The alternative worth weighing is the other DOS-era browsers, and the difference in approach is mostly about what they chose to leave out. MicroWeb is unusually permissive about the hardware it accepts, down to a serial port through the EtherSLIP driver and a 360K floppy image, and correspondingly limited in what it renders. Other period browsers push further on rendering and ask for more of the machine, and the practical comparison is: if the constraint is what the machine has, MicroWeb is the right shape; if the constraint is what the site needs, a different era of browser is.
Editorial conclusion
MicroWeb fits a retro computing collector or a preservation project that needs to read the web from hardware with no expansion card, since it runs on an 8088 with 640K of RAM and even a serial port through the EtherSLIP driver. It does not fit anyone who needs HTTPS, because TLS encryption is not supported and the workarounds are a translating proxy or a stripped-down rendering service, and it does not fit a modern page, since there is no CSS or JavaScript and only GIF images are rendered. Before you build or run it, read the command line options in the README, because the -noimages, -noems, -noxms and -useswap flags are the difference between a page that loads and a machine that hangs.
Frequently asked questions
What is MicroWeb?
It is a web browser for DOS that runs as a 16-bit real mode application and is designed to run on minimal hardware, such as an Intel 8088 with a CGA, EGA, VGA or Hercules compatible graphics card. It is written in C++ and licensed under the GPL-2.0.
What are the minimum hardware requirements for MicroWeb?
An Intel 8088 or compatible CPU, a CGA, EGA, VGA or Hercules compatible graphics card, and a network interface, although the machine's serial port can be used with the EtherSLIP driver. A mouse is desirable but not required, 640K RAM is desirable but it can run with less, and extra memory via XMS or EMS is recommended for heavier pages and images.
Does MicroWeb support HTTPS?
No. TLS encryption is currently not supported, so only HTTP servers can be accessed directly. The README offers two options: a proxy such as retro-proxy configured through the HTTP_PROXY environment variable, or the FrogFind! service, with MicroWeb generating a FrogFind link when it is redirected to an HTTPS site.
What images and scripts does MicroWeb handle?
Only GIF images are rendered, although PNG and JPEG dimensions are loaded for layout purposes. There is no CSS or Javascript support, and large or complex pages may be truncated if there is not enough RAM available. The -noimages command line option disables the image decoders entirely for very low memory setups.
How do I build MicroWeb from source?
You need the OpenWatcom 1.9 C++ compiler and you use OpenWatcom's wmake to build the makefile in the project/DOS folder. The README notes that it currently only builds in a Windows environment, and the root Makefile compiles with wpp and links with wlink using the system dos directive for a 16-bit executable.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/jhhoward-microweb)Was this useful?