vConsole: a mobile web debug panel that ships inside the page

What vConsole is for, and who actually needs it

The problem is ordinary: a web page misbehaves on a phone, and the phone has no developer console. Remote debugging over USB is not always available, WeChat's in-app browser does not hand you a desktop inspector, and a user reporting a bug cannot open DevTools. vConsole solves this by putting the debug UI inside the page itself. The README describes it as "a lightweight, extendable front-end developer tool for mobile web page", and the feature list is the familiar set: console methods, XMLHttpRequest, Fetch and sendBeacon traffic, an HTML element tree, Cookies, LocalStorage and SessionStorage, a manual JS command line, and custom plugins.

The audience is front-end engineers working on mobile web and hybrid apps. The README states that vConsole is framework-free and works in Vue, React or any other framework application, and that it is the official debugging tool for WeChat Miniprograms. That second point matters more than the first: if you ship a Miniprogram, this is the vendor-endorsed path, not a third-party hack. If you ship a plain mobile site, vConsole competes with nothing in particular, because the alternatives are desktop tooling you may not be able to attach.

How the panels hook into the page

vConsole is a runtime shim plus a UI layer. On construction it takes over the global console methods, so a later console.log does not only reach the browser's own console, it also lands in the vConsole Log panel. The README shows the same interception idea for network traffic: the Network panel covers XMLHttpRequest, Fetch and sendBeacon, which means it observes requests made through those APIs rather than reading a browser network log.

The panel set maps to browser surfaces: Element reads the live HTML element tree, Storage reads and writes Cookies, LocalStorage and SessionStorage, and System shows performance info. The README also documents a routing convention, where a leading [system] tag in the first argument sends that message to the System panel instead of the Log panel. That is a small design decision with a real consequence: log routing is by string prefix, not by a typed API, so a message that happens to start with that tag will move panels whether you intended it or not.

Extension happens through plugins, and the documentation splits into three files: plugin_getting_started.md, plugin_building_a_plugin.md and plugin_event_list.md. The repository also lists third-party plugins, including vConsole-sources, vconsole-webpack-plugin, vconsole-stats-plugin, vconsole-vue-devtools-plugin, vconsole-outputlog-plugin and vite-plugin-vconsole. Those are separate repositories, so their state is not covered by anything here.

Install vConsole with npm and read your first log

The README calls npm the recommended route. Installing the package gives you the module entry described in package.json, where main points at dist/vconsole.min.js and typings at dist/vconsole.min.d.ts, so TypeScript consumers get types from the published package.

npm install vconsole

Then construct it and log as usual. The README's example also shows the options form and the teardown call, which is the part people forget.

import VConsole from 'vconsole';

const vConsole = new VConsole();
// or init with options
const vConsole = new VConsole({ theme: 'dark' });

// call `console` methods as usual
console.log('Hello world');

// remove it when you finish debugging
vConsole.destroy();

After the constructor runs, a floating entry point appears over the page and console.log output shows up in the Log panel. The dark theme option is the one option the README names. When you are done, vConsole.destroy() removes it, which is why the README pairs the two calls in the same snippet.

The CDN route, and where the download question lands

If you cannot add a build step, the README gives an HTML method instead. The script exports the constructor onto window.VConsole by default, so no module system is involved.

<script src="https://unpkg.com/vconsole@latest/dist/vconsole.min.js"></script>
<script>
  // VConsole will be exported to `window.VConsole` by default.
  var vConsole = new window.VConsole();
</script>

Two CDN hosts are listed, unpkg and jsdelivr, both serving dist/vconsole.min.js. Both URLs use the @latest tag. That is convenient for a quick check on a device and a bad idea for anything you need to reproduce later, because the file behind the URL can change without your page changing. The README does not describe a version-pinning recipe, so if you need a fixed build, pin the version in the URL yourself or copy the file into your own assets. There is also a hosted demo at wechatfe.github.io/vconsole/demo.html, which is the fastest way to see the panels before installing anything.

Limits: runtime-only state, no remote pipeline, and the wrong-tool cases

Everything vConsole shows lives in the page. The README documents no transport that ships logs off the device, no server component, and no persistence across a reload. Close the tab and the captured network entries and log lines are gone. If your bug only reproduces after a navigation, or on a device you cannot hold, vConsole will not help you collect it.

There is a second boundary around the version. The latest release listed is v3.15.1 from 2023-06-01, while package.json on the default branch reads 3.16.0-alpha. The last push to the repository was on 2026-03-27. So the branch carries work that is not in a published release, and anyone installing from npm gets the older line. The README does not document a rollback procedure, and it does not state a support window, so treat the changelog as the only record of what changed and when.

It is also the wrong tool for production. vConsole intercepts global console methods and network APIs, and it renders its own UI over your page. The README's own example ends with vConsole.destroy(), which tells you the intended lifecycle: load it while debugging, remove it when finished. Shipping it to real users adds overhead and exposes an inspection surface to anyone who opens the page.

Compared with a desktop remote inspector

The closest alternative is the browser's own remote debugging, where a desktop Chrome instance attaches to a phone over USB and gives you a full DevTools session. The difference in approach is where the instrumentation lives. Remote debugging keeps the tooling on the desktop and streams from the device; vConsole puts the tooling in the page, so it needs no cable, no matching browser version, and no host machine. That is why it works in places remote debugging does not reach, such as a Miniprogram or an in-app browser that will not expose a debugging port.

The trade is capability. A desktop session gives you breakpoints, a call stack, and request timing you can sort and filter. vConsole gives you a panel sized for a phone screen and a manual JS command line. The repository also lists vconsole-vue-devtools-plugin among its third-party plugins, which is the pattern to expect: when vConsole lacks a view, someone writes a plugin rather than extending the core. If your problem needs stepping through code, the desktop inspector is still the right answer.

Maintenance, licence and the upgrade question

The repository is not archived, and the last push was on 2026-03-27. That is the whole of what the metadata supports about activity. The release cadence visible in the repository is slower than the commit activity: v3.15.1 landed on 2023-06-01, after v3.15.0 on 2022-11-02 and v3.14.7 on 2022-09-23. Anyone depending on a fix should check CHANGELOG.md and CHANGELOG_CN.md rather than assume the branch and the npm package match.

Upgrade cost is low if you use the npm route, because the package is small and its runtime dependencies are @babel/runtime, copy-text-to-clipboard and core-js, as listed in package.json. The CDN route is where cost hides: an @latest URL upgrades itself, and the README documents no pinning convention. Building the project yourself means webpack, Babel and TypeScript, and the package scripts expose separate web and wx targets through build and build:wx, so a Miniprogram build is not the same artefact as the web build.

The licence file is LICENSE, and the README links it as "The MIT License". The repository metadata does not carry a recognised SPDX identifier, so the machine-readable field and the README disagree in form. Read LICENSE before you rely on either. Nothing here is legal advice, and the plugin repositories are separate projects with their own terms.

Editorial conclusion

Adopt vConsole when you need to read logs and network traffic on a real phone or inside a WeChat Miniprogram and no desktop inspector is available, and load it from npm or a CDN script tag rather than bundling it into production. Do not adopt it if you need a long-lived remote log pipeline, server-side storage, or anything that survives a page reload, because the README documents none of that. Before you commit, verify three things against the repository: which build target you need (the package scripts expose both web and wx), where the current release sits relative to the v3.16.0-alpha version in package.json, and whether the plugin API in doc/plugin_getting_started.md covers the panel you wanted to add. The last push to the repository was on 2026-03-27, so check CHANGELOG.md for what actually changed after v3.15.1 before you assume a fix landed.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Tencent/vConsole on GitHub