What is JSX (JavaScript XML)?

If JSX still looks like HTML with a JavaScript accent, you are not alone. The confusion usually starts when a React component returns tags that seem familiar, but the rules are slightly different, the attributes change names, and the browser never runs the JSX directly.

What it is	JSX, a syntax extension for React component markup
Where it runs	Transformed by a build step before the browser sees it
Common tool	Babel, as of September 2026
Main use	Describing UI structure, logic, and component output in one file
Key benefit	Readable, declarative code that maps cleanly to React elements
Security behavior	Escapes values by default to help reduce XSS risk
Common mistake	Using HTML attribute names instead of JSX equivalents

What Is JSX in React?

JSX is the syntax React developers use to write component output in a form that looks familiar, even though it is not HTML. It lets you place markup-like structure directly inside programming logic, which makes it easier to read how data turns into interface elements.

That matters because React is declarative. Instead of telling the browser every step needed to build a button, a card, or a list, you describe what the UI should look like for a given state. JSX is the language-like layer that makes that description practical.

JSX is not “HTML inside JavaScript.” It is JavaScript-friendly UI syntax that React transforms into element creation code before the browser renders anything.

Here is the basic difference between old-school imperative DOM code and JSX-based React code. The first version is verbose and easy to break; the second version is easier to scan and maintain.

Imperative DOM	const h1 = document.createElement('h1'); h1.textContent = 'Hello'; root.appendChild(h1);
JSX React	return <h1>Hello</h1>;

The JSX version is more than shorter syntax. It keeps the structure, content, and conditional logic close together, which is exactly what you want when building reusable React components. That is why developers often search for “jsx online” or “how jsx works” when they are trying to make sense of React code they already see in the wild.

Official React documentation explains this model clearly, and it is worth reading the source instead of guessing from snippets alone: React: Writing Markup with JSX.

Why JSX Looks Like HTML but Is Not HTML

JSX looks like browser markup because it uses angle brackets, nesting, and child elements. That visual similarity is intentional. React wants UI code to be easy to read, and developers already understand the shape of HTML.

The important difference is that JSX is evaluated as code. You can embed expressions inside curly braces, use JavaScript variables, and pass values into components. HTML cannot do that on its own.

Key differences that trip up beginners

• JSX uses camelCase attributes in many places, such as className and htmlFor.
• JSX accepts JavaScript expressions inside curly braces, such as {userName} or {items.length}.
• JSX is compiled before execution, so the browser never parses it directly.
• JSX creates React elements, not raw HTML strings.

That last point matters for mental models. A React element is a plain JavaScript object that describes what the UI should be. React then uses that description to update the page efficiently. This is why JSX works so well with state, props, and component reuse.

For the official rules around element rendering and syntax expectations, React’s own docs are the most reliable reference: React: createElement. If you are using TypeScript in React projects, the TypeScript handbook also explains how JSX support is enabled in the compiler: TypeScript Documentation.

How JSX Works

JSX works by being transformed into regular JavaScript before the browser runs the app. The browser does not understand JSX syntax directly, so your build toolchain converts it into function calls or element objects that React can process.

1. You write JSX inside a React component, usually in a .jsx or .tsx file.
2. A compiler transforms it, often using Babel or the TypeScript compiler.
3. The output becomes JavaScript that calls React’s runtime helpers.
4. React builds a virtual representation of the UI from those element objects.
5. The browser receives updated DOM changes only where needed.

A simple example makes the flow easier to see:

const title = <h1>React Basics</h1>;

Conceptually, that becomes something like this after compilation:

const title = React.createElement('h1', null, 'React Basics');

Modern React setups often use the newer JSX transform, so you may not always see React.createElement in generated code. The important point is unchanged: JSX is not executed as-is. It is compiled first.

Babel is still the best-known JSX transformer, and the official Babel docs remain the clearest source for how the compilation layer works: Babel Documentation. For React-specific behavior, use the official React docs rather than guessing from old blog posts: React Learn.

Why the transformation step matters

• Compatibility because browsers only understand standard JavaScript.
• Optimization because toolchains can minify, bundle, and tree-shake code.
• Developer experience because linting, formatting, and hot reload work better in a build pipeline.
• Maintainability because modern toolchains catch syntax issues before deployment.

Basic JSX Syntax Every Beginner Should Know

Basic JSX syntax is simple once you learn the rules that matter most. A component can return one root element, that element can contain children, and you can use fragments when you do not want extra wrapper nodes in the DOM.

Here is the smallest useful pattern:

function Greeting() {
  return <h1>Hello, world</h1>;
}

If your component returns multiple sibling elements, wrap them in a parent element or a fragment.

function Profile() {
  return (
    <div>
      <h2>Ava</h2>
      <p>Frontend developer</p>
    </div>
  );
}

Fragments are useful when you want to group elements without adding an extra div to the DOM. That helps keep layouts cleaner and reduces unnecessary wrapper nodes.

function Stats() {
  return (
    <>
      <h3>Usage</h3>
      <p>128 active users</p>
    </>
  );
}

Small syntax rules that save time

• Self-closing tags must be written as <img /> or <input />.
• Child elements are written between opening and closing tags.
• Comments inside JSX use braces, such as {/* note */}.
• Lists should use stable keys when rendered from arrays.

The React official guide on rendering lists is a good companion read when you start building real UI: React: Rendering Lists.

How Does JSX Work with JavaScript?

JSX works with JavaScript through curly braces, which let you insert expressions directly into component markup. That means your UI can reflect data, conditions, and calculations without leaving the component file.

These are common valid examples inside JSX:

function Welcome({ user }) {
  return <p>Hello, {user.name}</p>;
}

function Total({ price, tax }) {
  return <p>Total: ${price + tax}</p>;
}

function Status({ isOnline }) {
  return <p>{isOnline ? 'Online' : 'Offline'}</p>;
}

What you cannot do is place arbitrary statements directly inside braces. For example, if statements, for loops, and variable declarations belong outside JSX expressions. If you need that logic, calculate the result first, then render the final value.

That separation keeps components readable. It also makes a “return jsx viewmodels article” style discussion more practical, because the structure of the view model and the structure of the UI often line up cleanly in React.

Common dynamic patterns

• Variables for user names, counts, and labels.
• Function results for formatted dates, prices, and derived state.
• Conditional rendering with ternaries or logical && expressions.
• List rendering with map() and a key on each item.

React’s official conditional rendering guide covers these patterns without mixing in framework noise: React: Conditional Rendering.

What Are JSX Attributes, Events, and HTML Differences?

JSX attributes often use camelCase because they map more closely to JavaScript property names than to HTML text. That is why className replaces class, and htmlFor replaces for.

Event handlers also follow JavaScript naming conventions. A click handler is written as onClick, and it usually receives a function reference, not a string.

function SaveButton() {
  const handleClick = () => {
    console.log('Saved');
  };

  return <button onClick={handleClick}>Save</button>;
}

Boolean attributes are another common source of confusion. In JSX, you can pass them as expressions instead of string values.

<input type="checkbox" checked={isChecked} />

Inline styles also work differently. In JSX, the style prop expects a JavaScript object, not a CSS string.

<div style={{ backgroundColor: 'navy', color: 'white' }}>Notice</div>

Beginner mistakes to avoid

• Using class instead of className.
• Using string handlers like onClick="save()" instead of onClick={save}.
• Forgetting braces around JavaScript values.
• Using lowercase HTML attributes where JSX expects a different name.

Official React DOM documentation is the best reference for attribute and event behavior: React DOM: Common Components. If you need a broader HTML reference for attribute naming, MDN remains useful for comparing the original markup model: MDN Web Docs.

How Does JSX Help with Security and Escaping?

JSX escapes inserted values by default, which helps reduce injection risk when rendering plain text. That default behavior is one of the biggest practical reasons React is safer than hand-built string concatenation for UI output.

If a user enters text like <script>alert('xss')</script>, JSX renders it as text instead of executing it. That behavior helps protect applications from common cross-site scripting problems when developers follow the normal rendering model.

Rendering user input as text is safe by default in React. Rendering raw HTML is where risk enters the picture.

The exception is dangerouslySetInnerHTML. Use it only when you must render trusted HTML, such as content already sanitized by a reliable server-side process or a vetted sanitizer. If the source is user-generated and untrusted, you should avoid direct HTML injection entirely.

Safer rendering habits

• Render text directly whenever possible.
• Sanitize HTML first if you truly need rich content from users.
• Prefer structured data over raw HTML blobs.
• Review sources carefully before using dangerouslySetInnerHTML.

For security guidance that aligns with application risk management, the OWASP Cross Site Scripting Prevention Cheat Sheet is the right reference point: OWASP Cheat Sheet Series. React’s own docs also explain escaping and HTML injection behavior directly: React DOM: dangerouslySetInnerHTML.

How JSX Supports Components and React Rendering

JSX is the normal way functional components return UI in React. A component can accept props, compute values, and return a JSX tree that changes when state or input changes.

That pattern is the heart of React’s declarative model. You describe the result you want, and React figures out how to update the screen efficiently. JSX makes that model easier to see because the component’s output is visible right inside the function.

function UserCard({ name, role }) {
  return (
    <article>
      <h2>{name}</h2>
      <p>{role}</p>
    </article>
  );
}

You can also compose components with children. That makes layouts and reusable UI pieces easier to manage.

function Page() {
  return (
    <main>
      <UserCard name="Mina" role="System Administrator" />
    </main>
  );
}

This is also where the “return jsx viewmodel react article” idea becomes practical. JSX gives you a readable view of how data maps to the rendered interface, which is especially useful when reviewing unfamiliar code or refactoring older components.

Why composition matters

• Smaller components are easier to test and reuse.
• Clear prop boundaries make data flow easier to trace.
• Nested components help teams split large interfaces into manageable parts.
• Declarative rendering keeps UI logic close to the output.

React’s composition and state model are documented directly by the React team, and those docs are the best source for exact behavior: React: Passing Props to a Component. For a broader ecosystem view, the React blog and release notes are also worth watching: React Blog.

Real-World JSX Examples

JSX shows its value fastest when you look at real UI patterns instead of abstract syntax. The examples below are simple, but they match code you will see in production React applications.

Example one: a profile card

function ProfileCard({ user }) {
  return (
    <article className="card">
      <img src={user.avatarUrl} alt={user.name} />
      <h2>{user.name}</h2>
      <p>{user.title}</p>
    </article>
  );
}

This is a clean example of JSX doing what it does best. Structure, data, and presentation sit together, but the component still reads naturally.

Example two: conditional login status

function AccountStatus({ isLoggedIn }) {
  return (
    <p>
      {isLoggedIn ? 'You are signed in.' : 'Please log in.'}
    </p>
  );
}

This pattern is everywhere in React apps: dashboards, auth banners, empty states, and notification messages.

Example three: rendering a list from an array

function TodoList({ items }) {
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.text}</li>
      ))}
    </ul>
  );
}

When people ask how JSX works in practice, this is often the answer. Arrays become repeated UI elements, and React uses keys to track each item efficiently.

For list and key guidance, the official React docs are still the best place to start: React: Keeping List Items in Order with key. If you want to compare UI output patterns with platform guidance, Microsoft Learn also offers solid examples of component-driven design in modern web apps: Microsoft Learn.

What Are the Most Common JSX Mistakes?

JSX errors are usually small syntax problems, but they can stop a component from compiling entirely. The good news is that most mistakes are repetitive and easy to diagnose once you know what to look for.

Frequent mistakes

• Missing closing tags on elements that must be closed.
• Returning siblings without a wrapper element or fragment.
• Using HTML attribute names like class instead of className.
• Forgetting braces around dynamic JavaScript values.
• Writing too much logic inline and making returns hard to read.

When debugging JSX, start with the compiler error. It usually points to the real issue or to the line immediately before it. If the error message looks confusing, simplify the component temporarily by removing nested conditionals and complex expressions.

A practical debugging workflow looks like this:

1. Check the first syntax error in the terminal or browser overlay.
2. Look for unmatched tags or an unclosed fragment.
3. Verify attribute names against JSX conventions.
4. Extract complex logic into variables above the return statement.
5. Rebuild the component one small piece at a time.

Tools and Workflow That Make JSX Easier to Use

Modern React workflows handle JSX almost automatically, but the tools still matter. Babel, the TypeScript compiler, bundlers, editor extensions, and formatters all help catch issues before they turn into runtime problems.

In practice, that means your editor can highlight broken tags, your linter can warn about bad patterns, and your dev server can refresh the page as soon as you save. That combination makes JSX much easier to learn because feedback is immediate.

Common tools in a JSX workflow

• Babel for transforming JSX into executable JavaScript.
• TypeScript for typed JSX support in .tsx files.
• ESLint for catching syntax and code-quality issues.
• Prettier for consistent formatting.
• Hot reload or Fast Refresh for quick iteration during development.

Tooling does not remove the need to understand JSX. It just reduces friction so you can focus on component design, state flow, and rendering behavior instead of fighting syntax all day.

For official setup guidance, start with the React documentation and your framework’s build docs rather than a generic tutorial. React’s own docs are the most stable source for current JSX behavior: React Learn. If you want the build-tool angle, Babel’s docs are still the most direct reference: Babel Documentation.

When Should You Use JSX and When Should You Keep Logic Outside the Markup?

JSX is best for presenting UI, not for packing every business rule into a return statement. A component should describe how the interface looks, while complex data fetching, transformations, and domain logic should usually live elsewhere.

That separation keeps components easier to test, easier to scan, and easier to reuse. It also prevents the common anti-pattern where a single return block turns into a hard-to-debug wall of conditions.

Use JSX when you need to

• Describe visible UI such as headers, cards, forms, and lists.
• Render conditional states like loading, empty, or error messages.
• Pass props into child components for reusable layouts.

Keep logic outside JSX when possible

• Business rules are better in helper functions or services.
• Complex data transforms are easier to test before rendering.
• Repeated logic belongs in custom hooks or extracted utilities.

A good rule is simple: if the code explains what the UI shows, JSX is the right place. If the code explains how the data is computed, move it out of the markup. That balance produces cleaner React components and fewer maintenance headaches.

The React team’s guidance on keeping components pure is a useful companion here: React: Keeping Components Pure. For broader coding quality principles, the National Institute of Standards and Technology (NIST) remains a reliable source for secure software and engineering guidance.

Conclusion

JSX is the syntax React uses to describe interfaces in a form that is readable, reusable, and tightly connected to JavaScript logic. It looks like HTML, but it is compiled into JavaScript before the browser runs the app, and that is what makes it powerful.

Once you understand JSX, React code becomes much easier to read. You can see how data moves into the UI, how components compose together, and why React applications are built the way they are.

The practical next step is simple: write a few small components, use variables and conditional rendering, and watch how JSX behaves in a real project. That hands-on repetition is what turns syntax into confidence.

For official reference material, keep these sources handy: React, Babel, TypeScript, and OWASP.