Low-Bandwidth Remote Access with VNC: What to Turn Down First

Yes, VNC works on a slow link, as long as the job needs the remote graphical display and you can live with a softer picture and slower redraws. It sends only the parts of the screen that changed, and only when the viewer asks, so a slow link gets fewer updates rather than a dead session. Your job is to make each update smaller and cap how often the server sends one.

On most desktops that means Tight encoding with a lower JPEG quality, a smaller remote desktop and a frame-rate cap on the server. Lower JPEG quality uses less bandwidth and CPU time but gives grainier images, so tune it against the text you actually have to read.

Where the bytes go

Your viewer drives the traffic. RFB updates are demand-driven by the client: the server sends one only when the viewer asks, and on a slow link the in-between screen states just get skipped. A static terminal costs almost nothing. A scrolling browser costs a lot.

Every update carries the changed rectangles, packed in the encoding and pixel format your viewer asked for in SetEncodings and SetPixelFormat. So you tune in two places. On the viewer, encoding, JPEG quality, compression level and color depth decide how big each update is. On the server, desktop size and the update-rate cap decide how many pixels change and how often they go out.

First, make sure the job fits a slow link at all. You need the remote display, not just a shell; you can work with a lag between typing and redraw; and the text and controls you need stay readable at reduced quality. If any of those fails, VNC tuning won’t save it.

When RDP is the better pick

If the target is a Windows machine and you don’t need the screen a local user is looking at, try RDP first. It runs continuous network detection and adjusts image quality, frame rate and codecs as the link changes; an active Word session in its default graphics mode measures 100 to 150 Kbps at 1920×1080. TigerVNC’s viewer adapts too, but coarsely: below 16 Mbit/s it drops JPEG quality to 6, and below 256 kbit/s it switches to a 64-color palette.

Pick VNC when you need the existing display, want to share it with the person sitting at it, or the remote machine isn’t Windows. RFB works at the framebuffer level, so the same viewer reaches X11, Windows and macOS servers.

Requirement	Pick	Why
Windows desktop, no need for the local user’s screen	RDP	Adapts codecs and frame rate to the measured link on its own.
The screen the local user sees, or a shared session	VNC	Shares the existing framebuffer; tune it with the settings below.
Mixed Linux, macOS and Windows targets	VNC	One protocol and one viewer across window systems.

Tight with JPEG for most desktops

Use Tight with JPEG for a normal desktop. TigerVNC’s automatic mode always picks Tight, and TurboVNC rates its Tight + Low-Quality JPEG preset as optimal on low-bandwidth connections. Tight only sends JPEG for rectangles with many unique colors and uses indexed color for the rest, so text and flat UI stay lossless.

If you need every pixel exact, ZRLE is the lossless choice in the RFB spec. It runs tiled run-length encoding with zlib over 64×64-pixel tiles, with one zlib stream per connection. Lossless encodings hold up on low-color screens such as CAD drawings, but on photos and gradients they cost far more than JPEG.

Higher compression levels trade server CPU for bytes. On a slow server, a high level can hold each update back longer than the link does.

Control	What it does	Use it when	Cost
TigerVNC `-QualityLevel`	JPEG quality 0 to 9, default 8.	Photos, gradients or video on the screen.	Artifacts on fine detail.
TigerVNC `-CompressLevel`	Lossless compression 0 to 9, default 2.	Text-heavy screens over a very slow link.	More server CPU per update.
TightVNC `-compresslevel`	Level 1 uses minimum CPU, level 9 compresses best.	High levels on very slow links, low levels on a LAN.	Level 9 is slow on the server.
noVNC `compressionLevel`	0 to 9, default 2.	Browser access through noVNC.	High levels slow the server down.

Turn down quality, desktop size and color

Lower JPEG quality cuts the bytes per update, and the artifacts land on exactly the detail you may need to read. TurboVNC’s Tight + Low-Quality JPEG preset runs JPEG quality 30, 4X chrominance subsampling and compression level 7, and 2X or 4X subsampling blurs lines and other sharp features. Judge any setting on the real window you have to read, not on an empty desktop.

Desktop size is the next lever. A 1280×720 session has fewer than half the pixels of the 1920×1200 desktop Debian’s tigervncserver creates by default, so every full redraw is smaller. Scaling in the viewer doesn’t help: noVNC’s scaleViewport scales the image locally while the server still sends every pixel, and only resizeSession asks the server for a new size.

Color depth is the last resort, for text work at a few hundred kbit/s. TigerVNC’s palette modes (8, 64 or 256 colors) are 8 bits per pixel, and the server only uses JPEG at 16 bits per pixel or more, so once you switch, -QualityLevel stops mattering.

A tuned TigerVNC session, start to stop

The run uses Debian 13 or Ubuntu 24.04 with a desktop already installed on the server, display :1 (port 5901), and the viewer on your workstation. Install the packages: