Dig in and Get the Most Out of CodeSandbox

Matt Dionis
Aug 19, 2019 · 7 min read
Photo by Markus Spiske on Unsplash

CodeSandbox is an awesome online code editor for spinning up and testing out new ideas quickly, sharing demo apps, collaborating, and even for getting larger projects started before moving them over to GitHub or another source control option.

Personally, I have used CodeSandbox to write both server-side (Node.js) and client-side (React) code. It’s my go-to choice for testing out new libraries (URQL), frameworks, and features (React Hooks). I’ve also used multiple CodeSandboxes like Legos and pieced them together. The best example of this is my Apollo Federated Gateway which links to a Location Service and a Weather Service. I then call this Gateway from my Apollo/URQL side-by-side React CodeSandbox. That’s four CodeSandboxes successfully working together! I like this approach because it allows anyone interested in learning about a separate piece of the stack to view, fork, and hack on just that isolated portion of code.

Four CodeSandboxes which rely on each other

CodeSandbox has many more options and features than you might guess at first glance. In this post, we will dive into some of the more powerful features of this awesome tool!


CodeSandboxes can be embedded in other sites so that users can view and play around with your sandbox. The quickest way to share a CodeSandbox project is to click on the “Share” button and choose one of the sharing options that appear in the lower right of the modal. However, there are about a dozen configuration options that you’ll want to become familiar with in order to customize your embeds.

CodeSandbox embed modal with configuration options



There are about a half dozen appearance options that you can tweak.

The view option determines the default view of the embed and can be one of “editor”, “split”, or “preview”. If you do not explicitly set this option it defaults to “split” for large screens or “preview” for smaller screens. If you want to show off a very visual sandbox, then “preview” is probably the way to go. Otherwise, “editor” is probably the best option. With limited screen real estate in an embed, I have found “split” to not often be a great choice.

The autoresize option is Medium-specific and automatically resizes the embed to the content. This option is off (0) by default but can be turned on by passing 1 to autoresize instead.

The hidenavigation option allows you to hide the navigation bar above the sandbox preview which shows the URL. This option defaults to “off” (0) but I often set it to 1 as I don’t find the navigation bar necessary in an embed.

Next up is the expanddevtools option which determines whether the devtools console is open (1) or closed (2). This option defaults to closed which is typically what you would want.

The moduleview option evaluates the file which is currently open in the editor. This option defaults to false (0) but if you have a use case for this you can set it to 1 to turn it on.

The previewwindow option allows you to choose what appears in the preview window if view is set to “split” or “preview”. This option defaults to “browser” but you can also set it to “console”, to display the devtools console, or “tests”, to display your test results.

Finally, the fontsize option allows you to set the, you guessed it, font size in px. This option defaults to 14.

Sandbox Options

There are also a few sandbox options that you can configure to your liking.

First off, there’s the codemirror option which is set to false (0) by default which means that the Monaco editor will be used. If you want to reduce your embed size significantly, you can set this to 1 to use the CodeMirror editor instead. This can be a nice performance optimization for your embed if you’re OK with using CodeMirror.

The next option in this section is eslint which is false (0) by default. If you want to enable ESLint, you can simply set this option to 1, but be aware that this will increase your embed size significantly.

Finally, the module option determines which module to open by default. This defaults to your sandbox’s entry path, but you can set it to whichever module you would like. You can even show multiple modules as tabs by entering a comma-separated list.

Other Options

The initialpath option defaults to / but you may set it to any valid string to show a different path on load.

The editorsize option allows you to set the editor size as a percentage and defaults to 50.

The forcerefresh option forces a full refresh after every edit and defaults to false (0).

If you have the codemirror option set to 1, you can pass a comma-separated list of line numbers to the highlights option to highlight lines of code.

The runonclick option allows you to only load the preview when the user chooses to. This option is set to false (0) by default.

Finally, the verticallayout option allows you to choose whether to display the editor and preview vertically (1) or horizontally (0, default) when view is set to “split”.

Example embeds

Let’s briefly walk through a couple of examples of embeds using the options discussed above.

In this first embed, I am aiming to focus on the code and also ensure the embed is as performant as possible. I, therefore, choose the editor-only view (view=editor) and increase the font size to 20 (fontsize=20). I also set codemirror to 1 to ensure a lighter weight embed. The resulting embed appears below.


In this next embed, I aim to show as much code as possible while keeping it readable, side-by-side with the resulting UI. To accomplish this, I set module to the file that I’m concerned with, /src/components/SettingsComponent.jsx, and I set fontsize to 12 in order to fit more code on the screen. The default view is “Editor + Preview” although you’ll notice that on smaller screens this defaults to just show the preview. Users can click the split screen icon to show the code side-by-side with the preview. The resulting embed is shown below.


Now that you know a bit more about embed options, make sure to tweak them to your liking the next time you embed a CodeSandbox project!

Importing and Exporting projects

CodeSandbox has some great tools both for importing existing projects into CodeSandbox and for exporting projects to GitHub.

CodeSandbox CLI

CodeSandbox has a CLI! Confession time: I was not aware this existed until a few days ago. To install the CodeSandbox CLI globally, run:

npm install -g codesandbox

Once the CLI is installed, you can export a project to CodeSandbox by running codesandbox followed by the directory you want to export. For example, if you are currently in your project’s top-level directory, simply run codesandbox ./.

This is a very convenient feature if you want to quickly share a local project with a broader audience. But what if you find yourself in the opposite situation? You have a CodeSandbox project which you would like to get under source control in GitHub. There is a CodeSandbox feature to cover this situation as well!

GitHub Integration

The CodeSandbox GitHub integration allows you to import any public GitHub repository and also to export any CodeSandbox project to GitHub!


To import a GitHub repo into CodeSandbox simply grab the URL of the repo and paste it into the CodeSandbox “Import from GitHub” feature. After a few seconds, you’ll have a copy of your project in CodeSandbox!

Importing a GitHub project into CodeSandbox


Exporting to GitHub is also possible. Simply click on the GitHub tab within your sandbox, enter the desired repo name, and click “Create Repository”!

Exporting a CodeSandbox project to GitHub

Live Collaboration

CodeSandbox has a feature which makes it easy to collaborate on a sandbox with others in real-time! As they describe it, “it’s like Google Docs, but for your code”.

How to “Go Live”

To go “live”, you simply click on the Live tab and then click “Go Live” to generate a URL which others can use to join your live session. The CodeSandbox team prepared a great demo of this feature which you can view below.

CodeSandbox Live demo

Using “Classroom Mode”

Classroom Mode allows you to decide who can edit the sandbox during a live session. This is helpful if you are teaching and want everyone to be able to work with the same sandbox but only yourself, or a limited number of people, to actually be able to edit the sandbox.


CodeSandbox has native integration with Jest Tests for running tests! You simply need to create files which end with one of the following: .test.js, .spec.js, .test.js(x), or .spec.js(x).


When you are ready to deploy a sandbox, you have two options: Zeit and Netlify.

To deploy using Zeit Now you will first need to create a Zeit account and log into it.

On the other hand, the Netlify integration allows you to deploy a sandbox even if you do not yet have a Netlify account. The following templates are available for Netlify deploys:


I hope you now have a better understanding of just how flexible and powerful CodeSandbox can be. Now get to building!

Matt Dionis

Written by

○ Engineering Manager @circlepay • GraphQL • React

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade