> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/customize-app/types-of-screens/content.md).
# Content
Content screens let you add a freeform page to a NotionApps app without connecting the screen to a Notion database. Use a Content screen when you need a welcome page, instructions page, landing page, help page, policy page, onboarding page, or public introduction page around the data-driven parts of your app.
Unlike List, Details, or Form screens, a Content screen is not for viewing or editing Notion records. It is for the static or semi-static information that helps users understand where they are, what they should do next, and how to move through the app.
## When to use a Content screen
Use a Content screen when the screen is mostly explanatory, branded, instructional, or navigational.
Good examples include:
* A public welcome page before users sign in.
* A landing page that explains what the app does.
* A help page with instructions for using the app.
* A policy, consent, or terms page.
* A dashboard introduction that links users to the right forms or lists.
* A lightweight marketing-style page inside a private or mixed public/private app.
* A launch page with buttons or links to public intake forms.
* A support page with contact details, process notes, or frequently asked questions.
Use a database-backed screen instead when users need to browse records, open one record, create records, update records, filter rows, or see live Notion data.
## Before you start
Before adding a Content screen, decide what job the page should do.
Ask these questions:
* Is this page for guests, signed-in users, or both?
* Should the page appear in navigation, or should users only reach it from a link or button?
* Does the page need to send users to a Form screen, List screen, Details screen, or external website?
* Is the app public, private, or a private app with selected public screens?
* Does the page need simple rich text, or does it need custom HTML and CSS?
This matters because Content screens can be used as public entry points in private apps, but only if you intentionally enable public access for the screen.
## Step 1: Add a Content screen
1. Open the app in the NotionApps builder.
2. Go to the screen list or screen management area.
3. Select **Add Screen**.
4. Choose **Content page** from the available screen types.
5. Give the screen a clear navigation name, such as **Welcome**, **Instructions**, **Help**, **Start Here**, or **About**.
The screen type may appear as **Content page** in the picker and as **Content** in navigation or short labels.
## Step 2: Open the Content page editor
After the screen is created, the builder opens the Content page configuration panel.
This panel is where you edit:
* The page content.
* The optional HTML source.
* The optional CSS source.
* Public access settings, when the app is private.
* Guest and signed-in navigation visibility, when public access is enabled.
* The live preview of the page.
The default content starts with a simple welcome message. Replace it with the copy, links, and layout that fit your app.
## Step 3: Use the visual editor for normal content
For most makers, the visual editor is the easiest place to start.
Use the visual editor to add:
* Headings.
* Paragraphs.
* Bullet lists.
* Numbered lists.
* Bold and italic text.
* Links.
* Images.
The visual editor is best when you want a clean page and do not need advanced layout control. You can write the page almost like a help article or landing-page draft.
Good visual-editor content usually has:
* A clear heading at the top.
* A short explanation of what the user can do.
* One or two obvious next actions.
* Links to the most important forms, lists, or external resources.
* Short sections instead of one long wall of text.
## Step 4: Add links carefully
Content screens are often used to route users to the next part of the app.
You can add links to:
* Another page in the same published app.
* A public Form screen link.
* A help article.
* A website.
* A payment, booking, or support link.
For best results:
* Use full `https://` URLs for external websites.
* Test every link in the published app after publishing.
* If the link should be available to guests, make sure the target screen is also public.
* If the link goes to a Form screen in a private app, make that Form screen public when guests need to submit it without signing in.
Same-app links are handled inside the app shell when possible, so users do not unnecessarily lose the app experience.
## Step 5: Add images
Images can make a Content screen feel more useful and polished.
Use images for:
* A logo or brand header.
* A process diagram.
* A screenshot that shows what users should do.
* A simple hero image.
* A visual explanation of a workflow.
Image URLs should use `https://`. Avoid images that are very large, private, temporary, or hosted somewhere that may block public access. If an image appears in the builder but not in the published app, check whether the image URL is publicly accessible.
Keep the page readable on mobile. Large images should support the content, not push the important action too far down the page.
## Step 6: Use HTML mode only when you need more control
The Content screen also includes an HTML editing mode for makers who need more control over layout.
Use HTML mode when you need:
* A multi-section landing page.
* Custom spacing.
* Button-style links.
* A custom grid or card layout.
* A more branded welcome page.
* More control than the visual editor provides.
HTML mode is powerful, but it is still intentionally limited for safety. Content screens are not a place to run custom JavaScript.
The system removes or blocks unsafe content such as:
* `