PyScript: running Python in the browser, and what maintenance mode means for adopters
An open source platform for Python in the browser. https://pyscript.net Docs: https://docs.pyscript.net/ Try it: https://pyscript.com/ Community: https://discord.gg/HxvBtukrg2
At a glance
- What is it?
- PyScript loads CPython or MicroPython into a web page through WebAssembly and lets you write Python inside HTML script tags. The project entered maintenance mode, and the last push was on 2026-09-07, so the question is no longer whether it works but whether you want to depend on it.
- Who is it for?
- Adopt PyScript for demos, teaching material, internal tools and anywhere a Python computation is cheaper than a server round trip; skip it for production front ends that need long-term support, since the README announces maintenance mode.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What PyScript solves, and the audience it actually fits
The browser runs JavaScript. If your logic is already written in Python, or your users are Python programmers rather than front end developers, you have historically had two options: rewrite the logic in JavaScript, or move the computation to a server and pay for the round trip. PyScript takes a third route. It loads a Python runtime compiled to WebAssembly into the page, so the Python executes on the visitor's machine, in the same document as the DOM it manipulates.
The README describes it as "an open source platform for Python in the browser" built on Pyodide, MicroPython and WASM. That framing sets the audience: data scientists who want to publish an interactive notebook, educators who want students to run Python without installing anything, and engineers who want to put a self-contained tool online without provisioning a backend. The README also points to an online IDE at pyscript.com and an examples gallery, which tells you the project expects people to try code before they commit to anything.
It is not a general replacement for a JavaScript framework. It is a way to put Python where JavaScript usually goes.
Two runtimes behind one script tag
The mechanism is visible in the README's own example. You include core.css and a module script, core.js, from a versioned path on pyscript.net. That loader then looks at script elements in the page and dispatches them according to their type attribute. The README's comment is explicit: "type mpy (MicroPython) or py (Pyodide) to run some Python".
So there are two execution paths. A script with type="py" is handed to Pyodide, which the README describes as a version of CPython. A script with type="mpy" goes to MicroPython. That distinction matters more than it looks. CPython compatibility means the standard library behaves the way you expect, at the cost of a larger download. MicroPython is a smaller interpreter with a reduced standard library, which is why it is a reasonable fit for small scripts and a poor fit for code that imports something exotic. Choosing the wrong one is the most common early mistake, and the README does not make the trade-off explicit beyond the parenthetical.
The loader also understands attributes such as terminal, which the example attaches to a MicroPython script that prints "Hello, world!". The README does not enumerate the full attribute set; the technical documentation at docs.pyscript.net is where that lives.
Installing PyScript and running a first page
There is no package to install for the browser side. The README's installation model is a CDN link pinned to a release, currently 2026.7.3. Create an HTML file and paste the following.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<link rel="stylesheet" href="https://pyscript.net/releases/2026.7.3/core.css" />
<script type="module" src="https://pyscript.net/releases/2026.7.3/core.js"></script>
</head>
<body>
<script type="mpy" terminal>
print("Hello, world!")
</script>
</body>
</html>Open the file in a browser. The interpreter downloads, the script runs, and the terminal attribute routes the output into a terminal panel on the page rather than the developer console. Expect a visible delay on first load, because the runtime is a WebAssembly binary and not a small one; the README gives no figure for it.
If you want CPython semantics instead, change the type attribute to py, which selects Pyodide.
<script type="py">
import sys
print(sys.version)
</script>Swapping mpy for py is the whole difference at the call site, but it changes the download size and the available standard library. For building the project itself rather than using it, the Makefile defines make setup, make build and make test, requires Node 20 or higher and Python 3.8 or higher, and refuses to install Python dependencies unless a virtualenv or conda environment is active.
The maintenance mode announcement changes the risk calculation
The first thing in the README after the title is an announcement: "PyScript is entering maintenance mode", linking to a gist. That sentence should drive the adoption decision more than any technical property of the runtime. Maintenance mode is not abandonment, and the repository is not archived; the last push was on 2026-09-07, and releases 2026.7.1, 2026.7.2 and 2026.7.3 shipped in July 2026. But the direction of travel is stated by the project itself, and the README does not promise a feature roadmap.
The practical consequence is that you should pin a version. The CDN paths are versioned, and the README's example uses releases/2026.7.3 rather than a floating latest, which is the right instinct here. A pinned URL will keep resolving even if development slows. What the README does not document is a rollback story, a deprecation schedule, or how long a given release path will remain hosted. If your deployment depends on that CDN continuing to serve a specific path, that dependency is unverified by anything in the repository.
A second limitation is inherent to the design rather than the maintenance status: the Python runs in the visitor's browser. Anything that needs a secret, a database credential or a large dataset is the wrong shape for PyScript, because the code and its inputs are on the client. The README does not discuss server-side execution, and there is no indication that it is in scope.
PyScript against Pyodide, and against staying in JavaScript
PyScript is not the only way to get Python into a page. Pyodide is the underlying CPython-to-WASM project, and the README names it directly as a dependency. Using Pyodide on its own gives you a JavaScript API and a Python runtime with no HTML conventions layered on top: you call loadPyodide yourself and manage the boot sequence. PyScript wraps that in script tags, a loader, a stylesheet and attributes like terminal, so the page author writes markup instead of bootstrapping code. The trade is familiarity for control. If you need to decide exactly when the runtime initializes, or you are embedding Python in an existing JavaScript build pipeline, the lower-level project is the more direct fit. If you want a Python script running in a static HTML file with no build step, PyScript is the shorter path.
The other alternative is to accept JavaScript. For DOM manipulation and event handling, JavaScript is already in the browser with no download. PyScript earns its place when the Python code is the point, such as a numerical routine, a parser or a teaching example, and loses when it is merely a familiar syntax for writing what a few lines of JavaScript would do. The README makes no claim that PyScript replaces JavaScript, and the search question asking whether it can is best answered by the runtime sizes rather than by ambition.
Licence and the cost of keeping up
The repository is Apache-2.0. That is a permissive licence: it allows commercial and closed-source use, and it includes an explicit patent grant. It also carries attribution and notice requirements, so if you redistribute PyScript or a modified build, keep the LICENSE and NOTICE material intact. This is a description of the licence text, not legal advice; if you are embedding it in a product, have your own counsel read the terms.
Upgrade cost is where maintenance mode bites. Because the browser side is a CDN link, upgrading is a matter of editing a version string in your HTML, which is cheap. The expensive part is testing, because a new release can change the runtime underneath you, and the README does not describe a compatibility guarantee between releases. The project's own build requires Node 20 or higher, npm 6 or higher and Python 3.8 or higher, so anyone building from source rather than consuming the CDN inherits that toolchain. The repository also ships a pre-commit configuration and a Makefile with fmt, fmt-check and precommit-check targets, which means contributing code carries formatting obligations as well as the usual review.
Where PyScript is the wrong tool
Reach for something else when the Python needs to touch anything private. There is no server in this architecture. A script that queries a database, calls a paid API with a key, or processes data you are not willing to hand to the client cannot be written this way without exposing those things, and the README offers no mechanism to prevent it.
Reach for something else when the page is mostly UI. The runtime is a WebAssembly download before the first line of Python executes, and a page whose main job is rendering a form with a few handlers pays that cost for nothing. Similarly, if your team writes TypeScript and ships through a bundler, adding a second language to the front end for a small amount of logic creates a maintenance seam that outlives the convenience.
And be cautious with long-lived public products. The README's own announcement is the signal: a project entering maintenance mode will still receive the attention its maintainers can spare, but the README does not commit to a support horizon. For a demo or a course, that is fine. For a product with a five-year life, it is a liability you should price in before you start.
Editorial conclusion
Adopt PyScript for demos, teaching material, internal tools and anywhere a Python computation is cheaper than a server round trip; skip it for production front ends that need long-term support, since the README announces maintenance mode. Before committing, verify three things yourself: that the pinned release URL you chose still resolves on the CDN, that your target browsers pass your own smoke test, and that the Pyodide or MicroPython runtime actually ships the packages your code imports.
Frequently asked questions
What is PyScript used for?
It runs Python inside a web page, so you can build interactive Python applications that execute in the visitor's browser without a server. The README describes it as an open source platform for Python in the browser, built on Pyodide, MicroPython and WebAssembly.
Is PyScript free?
Yes. It is an open source project and the repository is licensed under Apache-2.0, which permits commercial and closed-source use subject to the licence's attribution requirements.
Is PyScript still being developed?
The README carries an announcement that PyScript is entering maintenance mode. The repository is not archived and the last push was on 2026-09-07, with releases 2026.7.1, 2026.7.2 and 2026.7.3 published in July 2026, but the project itself states the change in status.
How do I install PyScript?
There is nothing to install for the browser side. You add a link to core.css and a module script pointing at core.js from a versioned path on pyscript.net, as shown in the README's example, and then write Python in script tags on the page.
How do I use PyScript in HTML?
You include the PyScript stylesheet and core.js in the head, then place a script element in the body with type="mpy" for MicroPython or type="py" for Pyodide. The type attribute decides which runtime executes the code.
Can PyScript replace JavaScript?
The README makes no such claim; it presents PyScript as a way to run Python in the browser, not as a substitute for the language the browser already ships. In practice the Python runtime is a WebAssembly download, so pages whose main job is DOM handling pay a cost JavaScript does not.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/pyscript-pyscript)