brow.sh

What is Browsh?

Browsh is a text-based browser that renders full modern web pages — HTML5, CSS3, JavaScript, video, even WebGL — as interactive text in a terminal. Rather than stripping pages down to plain text, it runs a real Firefox (version 57 or newer) underneath and paints the result into your TTY, so you can navigate, scroll and interact with sites that would normally require a graphical browser.

Its main purpose is to run on a remote server and be reached over SSH/Mosh or through a browser-based service, cutting bandwidth dramatically. That makes it useful when your connection is slow, metered or expensive, or when you want to browse from a machine with no graphical environment.

H3 Practical uses

• Low-bandwidth browsing: keep the heavy rendering on a server and send only text over the wire.
• Server and headless environments: browse from a VPS or container where no desktop exists.
• SSH-first workflows: reach a full browsing session from any terminal client.

H3 How you can try or install it

• A single static binary is offered for major platforms, with Firefox 57+ as the only stated dependency. A Docker image is also available (docker run -it browsh/browsh).
• The project lists a live SSH demo at brow.sh (no authentication, five-minute sessions, logged) and in-browser services at html.brow.sh and text.brow.sh, though the page notes these were temporarily offline. The text service is described as pure text and suited to curl.
• The page itself cautions that SSH is inefficient for this and recommends installing Browsh on your own server with Mosh for better results.

For a concrete scenario: if you pay per gigabyte on mobile data and need to check a JavaScript-heavy site, running Browsh on a cheap VPS and connecting with Mosh could cost you kilobytes instead of megabytes. If you only need to read static articles, a simpler text browser may be lighter; Browsh's advantage is fidelity on interactive pages.

Next step: check the current status of the demo services on Browsh before relying on them, and compare the binary and Docker installation routes against your server setup.

How do I install and run Browsh on my own server or computer?

Browsh ships as a single static binary for all major platforms, so installation is mostly about satisfying one dependency and then choosing how you want to run it.

What you need first

• A recent Firefox (version 57 or newer) installed on the same machine. Browsh drives Firefox to render pages and then translates the result into text for your terminal.
• A terminal client. For remote use, Mosh is recommended over plain SSH.

Install and run

1. Download the binary from the Browsh site for your platform, or pull the Docker image if you prefer containers.
2. Make the binary executable and place it somewhere on your PATH.
3. Run browsh in your terminal. It opens an interactive text rendering of a real browser session.

If you use Docker, the documented invocation is:

docker run -it browsh/browsh

Running it on a server

The intended deployment is on a remote server, accessed over SSH or Mosh. This is where the bandwidth argument matters: the server does the heavy rendering, and only text crosses the network, so browsing stays usable on slow or metered connections. Mosh handles intermittent connectivity better than SSH, which the project itself notes is inefficient for this purpose.

Trying it without installing

The project offers a live SSH demo at brow.sh — just point your SSH client there, no authentication required. Sessions last five minutes and are logged, so treat it as a test drive rather than a working environment. There are also in-browser services (html.brow.sh and text.brow.sh); the text version is plain enough to use with curl, though the HTML service does not yet match the terminal client feature-for-feature.

Choosing your setup

Practical note

Because Browsh renders through Firefox, expect it to feel like a browser squeezed into a terminal rather than a lightweight text browser. That is the trade-off: you get modern HTML5, CSS3, JavaScript, video and even WebGL support, at the cost of needing Firefox present and accepting terminal-grade interaction. If you only need to read simple pages, a conventional text browser will be faster and simpler; Browsh makes sense when the sites you need actually require a modern engine.

Next step: confirm your Firefox version before downloading, since an older Firefox is the most common reason Browsh fails to start.

How does Browsh reduce bandwidth and speed up browsing on slow or expensive Internet connections?

Browsh reduces bandwidth by moving the heavy work of rendering a page off your local connection. Instead of downloading full HTML, CSS, JavaScript, images, video and WebGL assets to your device, a modern Firefox engine renders the page on a remote server. Only a lightweight text-and-ANSI representation of the result is sent to your terminal. That cuts the amount of data crossing your link, which is the main reason browsing feels faster and costs less on slow or metered connections.

The page evidence describes Browsh as a fully interactive, realtime browser rendered to TTY, with its main purpose being to run on a remote server and be accessed via SSH/Mosh or an in-browser HTML service. It also states that it renders anything a modern browser can, including HTML5, CSS3, JS, video and WebGL. So the bandwidth saving does not come from stripping pages down to plain text in the way a text-only browser does; it comes from rendering normally on the server and transmitting a terminal-friendly view.

What actually travels over your link

• Your keystrokes and navigation commands go to the server.
• The remote Firefox instance fetches and renders the page.
• A compact terminal rendering comes back to your client.
• Large assets such as images, scripts, fonts and video are handled server-side rather than being pulled to your device.

That distinction matters if you are on a capped mobile plan, a slow rural line, or a satellite link. A conventional browser may need to download megabytes before a page is usable. Browsh's approach can make the same page usable after a much smaller exchange, because the bulky parts stay on the server.

Where the speed gain is largest

The benefit is greatest when pages are asset-heavy and your connection is the bottleneck. News sites, social feeds and JavaScript-driven apps with many images or fonts are typical examples. The benefit is smaller when the page is already mostly text or when the remote server itself is slow or far away. In that case, server latency and terminal rendering can become the limiting factors rather than bandwidth.

Browsh's own documentation notes that SSH is actually a very inefficient protocol and recommends installing Browsh on your own server along with Mosh for best results. That is a useful trade-off to understand: the bandwidth reduction is real, but the transport protocol still affects responsiveness. Mosh is designed to keep interactive sessions usable over high-latency or unreliable links, which is exactly the situation many slow-Internet users face.

A practical scenario

Imagine you are travelling with a laptop on a metered hotspot and need to check a documentation site, a webmail account and a news page. Running Browsh on a small cloud server and connecting over Mosh means the hotspot carries terminal traffic rather than full page assets. You keep the ability to interact with JavaScript-driven pages, but you are not paying to download every image and script to the laptop.

How to decide whether it fits

• Choose Browsh when your link is slow, capped or expensive and the pages you need are asset-heavy.
• Choose it when you already have a server or can run one, since the page presents a single static binary for major platforms with Firefox 57+ as the stated dependency, plus a Docker image.
• Think twice when you need pixel-accurate visual design, rich media playback on your own device, or when the remote server would add more latency than the bandwidth saving removes.
• Try the live SSH demo first if you want a quick feel for the interaction model; the page notes it is demonstration-only, with five-minute sessions that are logged.

For a next step, run Browsh on a server close to the sites you use, connect with Mosh rather than plain SSH, and compare a few representative pages against your normal browser on the same connection. If the terminal view covers your tasks, the bandwidth reduction is the main win; if you constantly need full visual fidelity, a conventional browser may still be the better fit. Related projects worth knowing include Website Name only if you already know its official domain; otherwise stick with Browsh's own documentation and release archive.

What are the differences between the SSH, HTML, and text in-browser services, and when should I use each?

Browsh offers three ways to view a modern web page without a graphical desktop: the SSH service, the HTML service at html.brow.sh, and the plain-text service at text.brow.sh. They differ mainly in how much rendering fidelity they preserve and how much bandwidth they consume.

• SSH service — You connect with a normal SSH client (for example, ssh brow.sh) and get the full interactive Browsh client. This is the closest to using a real browser: it renders HTML5, CSS3, JavaScript, video, and even WebGL, and you can navigate with keyboard and mouse-style interaction. It is intended for remote servers and is the best choice when you need a genuinely usable browser over a slow or expensive link.
• HTML in-browser service — html.brow.sh presents the same idea through a web page, using basic graphics and HTML anchor tags. It is convenient because you only need a browser, but the page notes it does not yet have feature parity with the terminal client, so some interactions or rendering may be limited.
• Text in-browser service — text.brow.sh outputs nothing but pure text. This is the lightest option and is explicitly described as better for tools like curl, where you want to fetch readable content rather than interact with a page.

A simple way to decide:

As a practical next step, try the SSH demo first if you want the real experience, then compare it with the text service for a scripted or low-bandwidth task. Note that the page states the live SSH demo and in-browser services were temporarily offline, and the SSH demo is for demonstration only with five-minute sessions that are logged. For regular use, the project recommends installing Browsh on your own server, ideally with Mosh, since SSH itself is described as inefficient for this purpose.

For reference, the project is at Browsh.

Can Browsh handle modern web features like HTML5, CSS3, JavaScript, video, and WebGL, and how does it compare to a normal browser in practice?

Browsh renders modern web content by running a real Firefox instance behind the scenes and translating the result to text. According to the project's own description, it handles HTML5, CSS3, JavaScript, video and even WebGL. In practice, that means the page is genuinely executed and laid out like a normal browser; what changes is the output, not the web platform support.

What this means in practice

• HTML5/CSS3/JS: Pages that depend on scripting and modern layout will generally load and run, because Firefox is doing the work.
• Video and WebGL: These are rendered rather than discarded, but you experience them as text/character output. You will not watch a video or interact with a 3D scene the way you would in a graphical browser.
• Interaction model: It is described as fully interactive and realtime, so links, forms and navigation work through the terminal, but the fidelity is inherently limited by the text medium.

How it compares to a normal browser

The main purpose is bandwidth reduction: running it on a remote server and accessing it via SSH/Mosh or the in-browser HTML service cuts bandwidth significantly, which speeds up browsing and lowers costs. The trade-off is visual fidelity—you get compatibility with modern sites, not a pixel-perfect experience.

A useful next step

If you want to test compatibility before committing, the project offers a live SSH demo (point your SSH client at brow.sh, no auth needed, sessions last 5 minutes and are logged) and in-browser services at html.brow.sh and text.brow.sh. Note that the page states these services are temporarily offline, and the HTML service does not yet have feature parity with the terminal client. For the best results, install Browsh on your own server alongside Mosh, since SSH itself is an inefficient protocol for this use case.

For comparison, a standard terminal browser such as Lynx handles far less modern content, while a full desktop browser gives you the complete visual experience Browsh deliberately trades away.

Why is Mosh recommended over SSH for using Browsh, and what are the trade-offs?

Mosh is recommended because Browsh renders a full modern browser—HTML5, CSS3, JavaScript, video—into a terminal, which means it continuously redraws a lot of screen state. SSH is a chatty, latency-sensitive protocol for that kind of interaction; Mosh is built to keep a remote session responsive and to survive flaky or high-latency connections. The Browsh page itself notes that "SSH is actually a very inefficient protocol" and suggests installing Browsh on your own server along with Mosh for best results.

The practical trade-offs

• Responsiveness: Mosh predicts and smooths local echo, so keystrokes and scrolling feel immediate even when round-trip times are long. SSH can feel laggy under the same conditions.
• Connection resilience: Mosh tolerates roaming and brief dropouts, reconnecting without dropping your session. Plain SSH usually dies when the connection breaks.
• Setup cost: Mosh needs to be installed on both the client and the server, and it uses UDP, which some networks and firewalls block. SSH is already everywhere.
• Use case fit: For a quick one-off look at Browsh, SSH is fine. For regular use over a slow or unstable link, Mosh is the better experience.

A useful next step: if you control the server, install Browsh there and connect with Mosh from your local machine; if you only want to try it briefly, the project's public SSH demo at ssh brow.sh works without authentication, though sessions are limited and logged. You can compare the terminal client with the project's lighter in-browser text modes at Browsh when deciding how much fidelity you actually need.