Tuesday JS: a visual novel editor that runs in the browser

Plain JavaScript and plain HTML elements as the whole engine

Tuesday JS is described as a simple web-based, free and open-source visual novel editor that can be used in a web browser. The defining technical decision is in the second sentence of that description: it is written in JavaScript without using any third party libraries, and therefore requires no additional software installation.

The engine uses standard HTML5 document elements such as div and img to write the game script. That single choice explains most of what the tool can and cannot do. Because a scene is a document, any media format the browser supports works, including vector graphics in svg, gif animations and css stylesheets. A background that would be a shader in a conventional engine is a CSS rule here, and a sprite animation is a stylesheet with keyframes.

The consequence is that there is no rendering engine to learn and no asset pipeline to maintain. You are working with the DOM, which means the ceiling on what a scene can look like is the browser, not the tool.

The repository layout matches that design. The engine itself is a single tuesday.js file at the root, alongside tuesday_visual.html for the editor and doc_runetime.html for the runtime documentation, with a plugins directory, a tools directory, a translate directory, an example directory and a lakit.json configuration file. The primary language of the repository is listed as HTML, which is accurate for a project where the document is the program.

The licence is MIT, and the last push was on 2026-09-20.

The same editor in a browser, on Android and on desktop

Tuesday JS is not only a web page. There is a version of the editor available as a standalone application for Android devices and desktops, and the readme makes a strong claim about that arrangement: all versions are fully compatible with each other and have the same interface.

That claim is what makes the standalone builds interesting rather than a convenience. A visual novel project is a set of text files plus media, and if the same editor and the same runtime can open a project in a browser, on an Android tablet and on a desktop, then the project does not have to be moved between tools when the audience moves. The readme points at the GitHub releases page for download builds for macOS, Windows, Android and Web.

The system requirements for the desktop version are modest, which is consistent with a tool that renders documents rather than compiling a game:

CPU: ARM / x86_64
RAM: 512 MB
Minimum OS:
- Windows 7
- MacOS 10.13 (Apple Silicon / Intel)
- Android 5.1
- Linux (Glibc 2.17 or newer)

Windows 7 as a floor and 512 MB of RAM tell you what kind of program this is. The oldest supported desktop is a decade old, and the memory requirement is small enough that a classroom machine or a cheap Android tablet can run the editor. The Linux entry names Debian 11 and Ubuntu 20.04 as the tested distributions.

For a visual novel author, that matters, because the target audience for an interactive story is not always the person with the newest laptop.

The visual editor shows the script structure, not just the text

The visualisation feature is what separates this from a plain text editor with a preview. The readme says the visual editor allows you to create graphics or kinetic novels without any programming knowledge, and that if it is necessary you can expand the basic functionality using JavaScript and css.

What the visual editor actually does is display the whole shape of the script, with the individual choices and the results those choices produce shown alongside each other. The stated benefit is that the structure of the script becomes visible at a glance, which makes the script easier to navigate and easier to edit. There is a screenshot of the script structure view, and it is the kind of view that a branching story with dozens of endings genuinely needs, because a linear text listing of such a script is close to unreadable.

That framing of the tool, as a thing for people without programming knowledge, is worth testing against your own project. A visual novel with branching choices and consequence tracking is close to the hardest kind of interactive writing to keep correct, and a tool that shows the branches together earns its keep there. A kinetic novel, which is essentially a timed sequence of images and text, is where the same tool is overkill and a text file would do.

The escape hatch is consistent with the rest of the design. JavaScript and css are available to extend the basic functionality, and the examples directory shows people using them, with files named for adding an element, replacing an image, and including a JavaScript library.

The scene editor previews other screen sizes before you ship

The scene editor handles placement, and it has one feature that is more than a drag and drop canvas.

It arranges all the elements in their places, and it also shows how the scene will change on different screens. In other words, you can see the layout on a phone and on a desktop before you commit to it, rather than finding out after a build.

The units are standard HTML ones, so you can specify a layout in percentage, pixels or centimetres, and the stated purpose is to adapt the scene to different screens. Percentage units are what make a scene survive a viewport change, and pixels are what let you pin a speech bubble to an exact spot. Having both in the same editor is the practical point.

The examples directory shows how far this goes in practice. There are example projects for a map, a quiz or test, spritesheets animation through css, animation with a choice, an incremental game, hidden objects, a game pad, mouse hover with css, a screen update triggered by onigi, a custom cursor, a comic style layout, an interactive movie, a language selection screen, entering a name, game time, and rock paper scissors.

That list is a better specification of the engine's capabilities than the readme prose. Map, incremental game, hidden objects and rock paper scissors are not visual novel features, they are general interactive story features, and the fact that they are all implemented as examples tells you the element model is general enough to build a small game with it, not only a branching story.

A built in translation tool, which is the feature that separates a hobby project from a release

The translation tool is the piece of the editor with the clearest reason to exist for a specific audience, and it is easy to underestimate how much work localisation is.

The built-in translation editing tool lets you add a new translation and edit all the texts in your project without leaving the editor. The Japanese description spells out the workflow: you add a translation for another language while referring to the original text used in the project, side by side like a bilingual table, so you do not have to launch a separate text editor. The tool also displays the number of completed translations for each language.

The progress count is the second important part, because localisation work is spread over months and a project with fifteen languages and three hundred strings is a project that needs to know where it stands.

The readme is also careful about the input side. The whole script is stored in a JSON structure, and because almost any programming language can work with that format, you can port your script to another engine or platform. The editor has a built-in tool for working with JSON, so you can edit the entire contents of the script or just the selected element.

That JSON decision has an effect on the whole project. A script that is a JSON file can be diffed, reviewed and merged with ordinary tooling, and a script that is a binary blob cannot. For a solo author that is mostly irrelevant, and for a team or a project that outlives one person it is the difference between a readable artefact and an opaque one.

Version 61, frequent releases, and the shape of the project

The release numbering is unusual and worth understanding before you pick a version. The recent releases are 61.0.0 (Tuesday JS Release 61) on 2026-09-20, 60.0.0 on 2026-07-13, and 59.0.0 on 2026-02-01.

So the major version is a serial release counter rather than a semantic versioning signal, and a jump from 59 to 60 is a routine release rather than a breaking change. That is fine for a solo-maintained tool where the author decides what a release contains, and it is a trap for automated tooling that reads major version bumps as compatibility breaks. If you pin the dependency, pin an exact release number.

The cadence is also visible in the dates, with three releases across 2026 and the last push on 2026-09-20, so the project is being worked on rather than sitting idle.

The repository itself is fairly flat. There is no build system, no package manifest and no test directory in the top level listing, which is consistent with a project that is plain files in a browser. There is a plugins directory, a tools directory, a translate directory with the localised editor pages, an example directory with two dozen example projects, a doc_editor.html for the editor documentation, and a _config.yml that is the GitHub Pages configuration.

The readme is also published in several languages, with the same content in English, Japanese, Russian and Chinese, and separate localised editor entry points under translate. A tool built for visual novel authors, whose audiences are rarely monolingual, was localised before most of its features were finished, which is a reasonable signal about where the author puts the effort.

Editorial conclusion

Adopt Tuesday JS if you want to write a visual novel or kinetic novel without installing anything, in a tool that stores the whole script as JSON so you can port it later, and if localisation matters to your project. Do not adopt it if you need a large team workflow, version control friendly project structure, or a rendering engine with effects the HTML document model does not give you, because the whole design leans on plain document elements. Before you commit, open one of the example JSON scripts, check that the browser builds run offline, and confirm the desktop and Android builds are where your test audience actually is.

Frequently asked questions

Official sources

1. Kirilllive/tuesday-js on GitHub
2. License: MIT
3. Project website
4. README
5. Releases