About Code Placement

When developing websites, it’s important to understand where to place your code so it runs in the right context, whether that’s in the browser, on the server, or across all pages. This article gives an overview of the different types of code files available, and explains when and how to use each one.

Supported IDEs

You can store your code using the following IDEs:

Frontend code

Frontend code runs in the site visitor’s browser and here you define the interactive parts of your site. This includes things like:

  • Responding to user input
  • Updating the UI
  • Making calls to backend services

Since this code is exposed to the public, avoid including sensitive information, such as API keys or private logic.

Use frontend code for:

  • Customizing how a page looks or behaves
  • Listening for events like button clicks or form submissions
  • Calling functions defined in backend web modules (.web.js)

Running code on all pages with Global code

Global code is code that runs on every page of your site. This is logic that's shared across all pages, such as managing a universal header or footer, or controlling global UI elements like a site-wide search bar or shopping cart icon.

To add global code, edit the masterPage.js file. You'll find it in:

  • Wix Studio: The Page Code section of the Code panel
  • Wix Editor: The Page Code section of the the Code sidebar
  • Local IDE: The src/pages folder when using Git integration

Important: masterPage.js has its own onReady event handler. Be careful not to duplicate logic from individual page onReady handlers, as both run in parallel.

Retaining an element's state

You can also use global code to retain an element’s state across pages. For example, if you change the source of an image element that appears on all pages, that change won’t persist when navigating to another page, or even when returning to the original page.

To make changes persistent across pages, use the wix-storage-frontend API:

  1. In the relevant event handler, call setItem to store a value that reflects the element’s new state.

  2. In the masterPage.js onReady function, read the stored value and update the element accordingly.

Note: Avoid importing functions from masterPage.js into individual page files. Doing this causes the onReady function in masterPage.js to run twice on those pages. For shared logic, create code on a separate public file and import it where needed.

Running code on a specific page

Each page on your site has its own code file. Use these files to add functionality that's specific to that page, for example:

  • Handling user input
  • Customizing UI behavior
  • Calling backend functions.

Public files

If you find yourself repeating the same code across multiple page files, it's better to move shared logic to a separate public file. That way, you can write it once and import it wherever it's needed: Whether in a page file, a backend file, or another public file.

To share a function across multiple files:

  1. Create a public file and export the function from it.

  2. Import the function into any page where it’s needed.

You can find your public files in:

  • Wix Studio: The Backend & Public section of the Code panel
  • Wix Editor: The Backend & Public section of the the Code sidebar
  • Local IDE: The src/public folder when using Git integration

Use ES module syntax (import/export) to access functions between files. Always include the function name in curly braces when importing a named export:

Copy

Leaving out the curly braces attempts to import a default export:

Copy

Unless myFunction was explicitly exported as the default, this will throw a runtime error:

Copy

To access all functions from a module, import the entire module without curly braces:

Copy

Tip: Your page code, which is also publicly accessible, doesn't appear in the list of public files. To see your page code, go to the Page Code section and click on the page in the menu.

Responding to element actions with event handlers

Page elements like buttons, text, and input fields can trigger events when site visitors interact with them. The functions that handle these events are called event handlers.

There are following types of event handlers:

HTML

Adding raw HTML directly in the code editor isn't supported.

That said, there are several ways to include or work with HTML on your site:

Backend code

Backend code runs on Wix’s secure servers and isn’t exposed to site visitors. This is the place for logic that needs to be protected, like:

  • Interacting with sensitive data
  • Sending emails
  • Handling payments
  • Verifying permissions

Use backend code for:

  • Perform secure database operations
  • Respond to frontend requests by using web modules
  • Handle server-side events and scheduled tasks
  • Expose custom HTTP methods to other services

Backend files

Backend files are where you define server-side logic. They include code that runs securely on the web server rather than in the browser. This is where you define functions from backend libraries such as wix-pay-backend, wix-members.v2, or wix-events.v2.

You can find your backend files in:

  • Wix Studio: The Backend & Public section of the Code panel
  • Wix Editor: The Backend & Public section of the the Code sidebar
  • Local IDE: The src/backend folder when using Git Integration

There are 2 main file types used in the backend:

  • .web.js: Web modules that can be called from the frontend. You can configure permissions for each function to control who can access them. Learn more about the .web.js files in About Web Modules.
  • .js: Internal backend files that can't be accessed directly from the frontend. Use these for secure server-side logic.

Note: You may also see .jsw files in older projects. These have been deprecated in favor of .web.js files but are still supported. Learn more about the .jsw files in Call Backend Code from a jsw Web Module.

Accessing functions from a .js file

To access functions from a .js file in the frontend, import the function into a .web.js file first, then import that .web.js function into your frontend code.

Import the .js file into the .web.js file:

Copy

Import the .web.js file in your page file:

Copy

If you try to import a .js file directly into a frontend file, you'll see this error:

Copy

Backend events

Many Wix modules provide built-in events that trigger when specific actions occur. For example, uploading a file to the Media Manager triggers the onFileUploaded event, and successfully paying an invoice triggers the onInvoicePaid event. These events let you run custom logic in response to key moments in your site’s workflow.

To run an event, you need to add an events.js file. Learn more about adding backend events in About Backend Events.

Handling HTTP requests

To expose your site’s functionality to the outside world, like enabling GET, PUT, POST, or DELETE requests from external services, you can define custom HTTP methods.

To create an HTTP function, you need to add an http-functions.js file. Learn more about the HTTP functions in About Custom Site APIs.

Using data hooks when data collection changes

Data hooks let you run code before or after changes are made to your site’s data collections. They’re useful for validating, modifying, or responding to data operations like insert, update, or remove.

To create data hooks, add a data.js file to your backend code. You can then define functions that correspond to specific data operations on your collections. Learn more about data hooks in Using Data Hooks.

Routers

By default, Wix uses built-in routers to handle dynamic page URLs and SEO. If you need more control over how incoming requests are handled, you can create your own custom router to define the logic, routing, and data for each request.

The code for both routers and data binding router hooks is defined in the routers.js file. Learn more about routers in About Routers.

Secrets Manager

For sensitive information like API keys, OAuth tokens, or configuration settings, use the Secrets Manager instead of hardcoding values into your code. Secrets are stored securely in your site's dashboard and can be retrieved in code using the Secrets API.

Storing secrets in the Secrets Manager improves your site's security, especially when you're collaborating with others or using version control. Each secret has a unique name, and you can access it safely in backend code without exposing it to site visitors.

See also

Did this help?