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.
You can store your code using the following IDEs:
Frontend code runs in the site visitor’s browser and here you define the interactive parts of your site. This includes things like:
Since this code is exposed to the public, avoid including sensitive information, such as API keys or private logic.
Use frontend code for:
.web.js)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:
src/pages folder when using Git integrationImportant: masterPage.js has its own onReady event handler. Be careful not to duplicate logic from individual page onReady handlers, as both run in parallel.
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:
In the relevant event handler, call setItem to store a value that reflects the element’s new state.
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.
Each page on your site has its own code file. Use these files to add functionality that's specific to that page, for example:
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:
Create a public file and export the function from it.
Import the function into any page where it’s needed.
You can find your public files in:
src/public folder when using Git integrationUse ES module syntax (import/export) to access functions between files. Always include the function name in curly braces when importing a named export:
Leaving out the curly braces attempts to import a default export:
Unless myFunction was explicitly exported as the default, this will throw a runtime error:
To access all functions from a module, import the entire module without curly braces:
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.
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:
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 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:
Use backend code for:
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:
src/backend folder when using Git IntegrationThere are 2 main file types used in the backend:
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.
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:
Import the .web.js file in your page file:
If you try to import a .js file directly into a frontend file, you'll see this error:
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.
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.
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.
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.
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.