noVNC

Last reviewed Sep 13, 2026 · 878 words

Most people who search for noVNC want a remote desktop they can open in a browser, and noVNC is only half of that. It is the client: a JavaScript program that draws a VNC session onto an HTML canvas. It still needs a VNC server on the target machine and a WebSocket proxy (websockify, which ships with it) in between, because browsers cannot open raw TCP sockets. Once you know that, noVNC is easy, useful, and everywhere; you have almost certainly used it inside Proxmox, oVirt, or an OpenStack console without noticing.

What noVNC actually is, in one diagram's worth of words

The chain is browser, then websockify, then VNC server on port 5900. websockify accepts a WebSocket on port 6080, unwraps the frames, and forwards bytes to the VNC server as plain TCP. noVNC's JavaScript speaks the RFB protocol over that WebSocket, handles keyboard and mouse, and renders framebuffer updates to a canvas. No plugin, no Java, no install on the client side, which is why it survived from 2010 to 13,985 stars while every other browser remoting approach died with Flash and NPAPI.

The quickest test on a box that already runs a VNC server:

git clone https://github.com/novnc/noVNC
cd noVNC
./utils/novnc_proxy --vnc localhost:5900

That starts websockify serving the noVNC pages on port 6080, and http://host:6080/vnc.html gives you a working desktop. From there it is a question of how you want to lock it down.

TLS is the difference between a tool and a liability

VNC authentication is weak, and the websockify hop is plaintext by default, so a noVNC page reachable from outside your LAN needs TLS in front of it. websockify takes --cert and --key directly, but the cleaner pattern is to keep websockify bound to localhost and terminate TLS on a reverse proxy that also handles authentication. Caddy does this in a four-line site block with WebSocket support built in; put basic_auth or a forward-auth to your identity provider on that block and VNC's own password becomes a second layer rather than the only one. On a LAN, the same rule applies if you would not be happy with a housemate watching your session.

Where you meet it without installing it

The reason to understand noVNC is that it is embedded in things you already run. Proxmox VE's console button is noVNC. KasmVNC pairs a TigerVNC-derived server with a client descended from noVNC, and Kasm Workspaces builds a whole product on top of that. Many Docker "desktop in a browser" images (the linuxserver webtop family among them) bundle it. Home Assistant add-ons, JupyterHub desktop spawners, and QEMU's -vnc option plus websockify are all the same three-piece chain. If you are building an app and need to show a remote screen, the RFB class in core/rfb.js is what you embed, and the API is small enough to read in an afternoon.

When a heavier tool is the better call

noVNC gives you one VNC connection per page with no user management, no session list, no recording, and performance that trails native clients because the framebuffer goes through JavaScript and a canvas. Three things push you elsewhere. If you want a web portal that lists many machines, supports RDP and SSH as well as VNC, and has real user accounts, that is Apache Guacamole, which uses a similar HTML5 client but wraps it in a full gateway. If you want fast, low-latency access to your own desktops from anywhere with encryption by default, that is RustDesk with a self-hosted relay, and my full setup is in the RustDesk guide. If the target is Linux and you care about responsiveness, KasmVNC's server pairs with the same browser client and is markedly quicker than TigerVNC plus websockify.

Sizing and the small gotchas

Resource use is trivial: websockify is a Python process in a few tens of MB, and the catalogue's 64 MB floor is mostly Python's overhead. The things that catch people are mundane. Clipboard sharing works for text only and needs the VNC server to support it. Keyboard layouts other than US can produce wrong characters unless the server and client agree, and the "Show Extra Keys" toolbar exists because Ctrl-Alt-Del does not arrive naturally through a browser. Scaling settings are in the side panel, and "Remote Resizing" only works if the VNC server supports the SetDesktopSize extension, which TigerVNC does and older servers do not.

What I'd do

Use noVNC where it already lives and do not fight it: Proxmox consoles, VM emergency access, a kiosk screen you need to see occasionally. For deliberately exposing a machine, run a VNC server bound to localhost, websockify on localhost, Caddy with TLS and forward-auth in front, and never leave port 6080 open. For day-to-day remote desktop use across several machines, skip straight to Guacamole for the gateway case or RustDesk for the "my own PCs" case, both of which are in remote access; noVNC is the piece they are built from, not the product you run for its own sake.