React JSX
A JSX file is source code for building web interfaces — HTML-style tags inside JavaScript. Created by Facebook in 2013 for the React library, JSX has no MIME type, no magic bytes, and no standards body — a build tool like Babel translates it to JavaScript before any browser sees it.
JSX conversion is not yet available in FileDex. For now, use the CLI commands in the Developer Door to transpile JSX to JavaScript with Babel or SWC.
Common questions
How do I open a .jsx file?
Any code editor opens a .jsx file as text. VS Code, WebStorm, and Sublime Text all show JSX with color-coded syntax. To run the code, however, you need a build tool like Vite or Create React App that converts JSX into regular JavaScript first — browsers cannot read .jsx files directly.
What's the difference between JSX and HTML?
HTML is what browsers read to display web pages. JSX is a writing style developers use to make their JavaScript code look more like HTML. JSX always gets translated into regular JavaScript before a browser sees it. Most web pages today use both — HTML at the browser, JSX in the source code.
Is JSX valid JavaScript?
No. JSX is not part of the JavaScript language — JavaScript engines do not recognize the angle-bracket tags JSX uses. A translator tool (the most common is called Babel) rewrites every JSX file into regular JavaScript before any browser or server runs it. Without this translation step, JSX produces a syntax error.
Why does a .jsx file need a build step?
No JavaScript engine reads JSX directly. Browsers and Node.js expect plain JavaScript syntax — not the HTML-style tags JSX adds. A build tool like Babel or Vite translates the file into regular JavaScript before any runtime sees it. Frameworks like Next.js automate this build step in the background.
Is JSX only for React, or is it used elsewhere?
JSX started with React in 2013 but now has multiple implementations. Preact, Solid, Inferno, and Stencil all accept JSX syntax and compile it to their own component models. TypeScript's `.tsx` variant adds static types on top. Vue, Svelte, and Astro offer JSX as an optional authoring style. The syntax is maintained as a Meta draft spec rather than a standard — each framework picks its own runtime semantics.
What makes .JSX special
Open a .jsx file in a web browser. Nothing happens. Open it in Node.js. Same thing. JSX looks like a programming language, but no software actually reads it directly — it always passes through a translator first. That detail shapes everything else about how JSX works.
Continue reading — full technical deep dive
Send a .jsx File to Your Browser. Nothing Happens. Why?
Send a .jsx file to a browser and nothing happens. Open it in Node.js — same result. Run it in any JavaScript engine on Earth and you'll get a syntax error before the first line executes.
JSX isn't actually JavaScript. It's a writing style developers use that looks like JavaScript with HTML tags inside it. Real JavaScript engines have no idea what to do with the angle-bracket tags JSX uses — those aren't part of the language. So before any browser ever sees your code, a translator program (Babel is the most common one) rewrites every JSX file into plain JavaScript that the browser does understand.
This means the .jsx file you write and the .js file the browser runs are different files. The browser never reads the code you typed. It reads the translated version.
This sounds inefficient, but it's the trade-off React made for readability. Writing tags is friendlier than typing the equivalent function call by hand. The price is one extra step — a build process — between writing code and running it. Every React project, every Vite app, every Next.js website does this translation behind the scenes. That's why opening a .jsx file in your browser does nothing: it was never meant to be opened directly. Which raises a question: if no browser runs it, who standardizes it?
No Magic Bytes, No MIME Type, No Standards Body. How Is JSX Even a File Format?
Most file formats have a paper trail. PNG has an ISO standard. PDF has a public spec from Adobe. HTML has a body called WHATWG that updates the rules. JSX has none of these.
There is no formal JSX specification. The closest thing is a draft document Meta posted on a GitHub page that hasn't changed much since 2015. There is no registered MIME type — when web servers serve a .jsx file, they have to guess what to call it. There is no magic-byte signature inside the file, so software has to look at the file's name to know it's JSX. There is no version number. The 'spec' is whatever the most popular tools — Babel, the TypeScript compiler — decide to support this year.
This regulatory vacuum is unusual for a format with tens of millions of files in circulation. HTML has WHATWG. CSS has W3C. JavaScript has Ecma TC39. JSX has GitHub issues.
It works because the tooling converged. Anyone who ships JSX uses Babel or one of its near-identical alternatives, and they all translate JSX the same way. So even without a standards body, you can move a JSX file between projects and expect it to compile the same way everywhere. The lack of a formal spec is invisible — until you try to find one. The lack of a spec also explains one small-but-giveaway design choice that every JSX file carries.
One Word Identifies JSX Instantly. Which One?
Open any JSX file and look for className. HTML uses class for styling. JSX uses className. One word reveals the whole story.
The reason has nothing to do with JSX wanting to be different. JavaScript already uses class as a reserved word — it means 'I am declaring a new type of object.' So when JSX gets translated into JavaScript, class would clash with JavaScript's existing meaning. The translator handles this by renaming JSX's class to className everywhere.
The same pattern repeats throughout JSX. HTML's for attribute (used on form labels) becomes htmlFor. HTML's lowercase onclick event becomes camelCase onClick. The style attribute, which HTML writes as a CSS string, gets a JavaScript object instead. All of these renames exist for the same reason — JSX has to translate cleanly into JavaScript without colliding with words JavaScript already uses.
If you're writing HTML and decide to convert it to JSX, these are the rules you'll trip over first. There are autocomplete tools that handle the mapping for you, but they all follow the same pattern: when JavaScript already owns a word, JSX has to use a different one. The seemingly arbitrary spelling differences are actually a careful translation choice. A translation from JSX to JavaScript that happens hundreds of times in every build — and different tools make it slightly differently.
The Same JSX File Compiles Into Different JavaScript Depending on the Tool. Why?
The same JSX code can power three completely different websites depending on which library you pair it with.
React is the original. It takes your JSX, translates it into JavaScript objects representing the user interface, and tracks changes by comparing those objects every time something updates. This 'virtual DOM' approach (a working copy of the page kept in memory) made React famous in 2013 and powers most of the modern web.
Preact does almost the same thing, but in a fraction of the size. The Preact team rewrote React's core ideas into a 3-kilobyte library. Most code that works in React works in Preact too — you can swap one for the other without rewriting your JSX files.
SolidJS takes the same JSX syntax in a totally different direction. It throws away the virtual DOM. Instead, it tracks which specific values change and updates only the parts of the page that depend on them. The JSX you write looks identical, but what runs underneath is fundamentally different.
This is why JSX matters as a syntax independent from React. You can write JSX once and choose your engine — React for the standard ecosystem, Preact for size constraints, Solid for performance. The same angle brackets, three different ways to bring them to life.
.JSX compared to alternatives
| Formats | Criteria | Winner |
|---|---|---|
| .JSX vs .TSX | Type safety and developer experience TSX adds TypeScript's compile-time type checking for props, state, and events. JSX relies on runtime PropTypes or no type checking. TSX is recommended for production projects. | TSX wins |
| .JSX vs .VUE SFC | Component architecture JSX co-locates markup and logic in JavaScript. Vue Single File Components separate template, script, and style in one file. Both approaches are productive; choice is ecosystem preference. | Draw |
| .JSX vs .SVELTE | Runtime performance Svelte compiles components to imperative DOM updates at build time with no virtual DOM. React/JSX uses a virtual DOM diffing algorithm at runtime, adding overhead. | SVELTE wins |
Technical reference
- MIME Type
text/jsx- Developer
- Meta (Facebook)
- Year Introduced
- 2013
- Open Standard
- Yes
Binary Structure
JSX is plain UTF-8 text with no binary signature, no magic bytes, and no registered MIME. A typical JSX file follows a predictable structure: an `import` block at the top (pulling React or other libraries), one or more function or class components, and a default or named `export` at the bottom. Components return JSX expressions — HTML-like markup wrapped in parentheses after the `return` keyword. Identification relies on text markers instead of hex offsets: the pattern `import React` or `import { useState } from 'react'` near the top is the strongest signal that a .jsx file contains React JSX specifically. The angle bracket following `return (` indicates the JSX block. Files are never executed directly — Babel, SWC, or esbuild transforms them into `_jsx()` or `React.createElement()` calls before any runtime sees them.
| Offset | Length | Field | Example | Description |
|---|---|---|---|---|
Line 1 | variable | Import declaration | import { useState } from 'react'; | JSX files typically open with one or more import statements. React imports signal React JSX; 'solid-js' imports signal Solid.js JSX. |
Line N | variable | Component definition | function MyComponent({ title }) { | Components are plain functions (or class declarations in legacy React) that return JSX. Component names must start with a capital letter. |
Line N+1 | variable | JSX return | return (\n <div className="wrapper"> | JSX markup appears after the `return` statement. The first `<` opens the JSX block; parentheses wrap multi-line expressions. |
Last line | variable | Export | export default MyComponent; | Components are typically exported as default or named exports for import in other files. |
JSX conversion is not yet available in FileDex. For now, use the CLI commands in the Developer Door to transpile JSX to JavaScript with Babel or SWC.
Attack Vectors
- XSS via dangerouslySetInnerHTML
- Supply chain attacks via npm
- Prototype pollution via spread operators
Mitigation: Treat JSX files from unknown sources like any source code. Scan for suspicious imports, `eval` calls, or base64 payloads before installing or running. Run npm audits on project dependencies to detect known supply-chain compromises. Never execute JSX without reviewing the transpiled JavaScript output. FileDex does not parse or run JSX — this page is static, no upload.
- Specification JSX Draft Specification — Meta
- Documentation React — Writing Markup with JSX
- Documentation Babel @babel/preset-react
- Documentation TypeScript JSX Handbook
- Documentation MDN — Introduction to JSX