🎛️Content
Learn how to use Content screens for landing pages, help pages, public entry points, and static app 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
Open the app in the NotionApps builder.
Go to the screen list or screen management area.
Select Add Screen.
Choose Content page from the available screen types.
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:
<script>tags.Inline event handlers such as
onclickoronerror.Iframes, embeds, objects, meta tags, base tags, and link tags.
Unsafe
javascript:,vbscript:, or risky data URLs.
The HTML limit is approximately 100,000 characters.
Step 7: Add CSS when the page needs custom styling
CSS is optional. Use it when the Content screen needs to match your brand or create a more polished layout.
CSS is useful for:
Buttons.
Cards.
Spacing.
Background colors.
Typography.
Responsive sections.
Simple grids.
Keep CSS focused on the page itself. Avoid styles that try to override the full NotionApps app shell, navigation, login screen, or unrelated screens.
The CSS limit is approximately 50,000 characters. If the CSS is too large or invalid, the builder may reject it.
Step 8: Preview the page
The preview area shows how the Content screen will render.
Use preview to check:
The top heading is clear.
Important links are visible.
Text is easy to read.
Images load correctly.
The page does not feel too long.
The page works on smaller screens.
The next action is obvious.
Preview is especially important when using HTML and CSS. A page can look fine in source form but feel cramped, oversized, or confusing in the actual app shell.
Step 9: Configure public access when needed
If your app is private, you can make a Content screen public.
Turn on Public access when anyone with the app link should be able to open that Content screen without signing in.
This is useful for:
A public welcome page.
A public onboarding page.
A public help page.
A public landing page that links to a public intake form.
Public access applies to the selected screen. Other private screens stay private unless you also mark them public.
If the app itself is already public, users can already open the app without signing in, so the public access setting is mainly important for private apps that need a public entry point.
Step 10: Decide whether guests should see it in navigation
When a Content screen is public, you can decide whether guests see it in the app navigation.
Use Show in navigation for guests when:
The page is a normal public page guests should find from the menu.
The page is the public home or welcome page.
You want users to return to it easily.
Turn guest navigation off when:
The page should only be opened from a direct link.
The page is part of a one-time flow.
You want to keep guest navigation very simple.
A public screen can still be opened by link even if it is hidden from guest navigation.
Step 11: Decide whether signed-in users should see it in navigation
Public screens can also have separate navigation visibility for signed-in users.
Use Show in navigation when signed in when:
Signed-in users should still have easy access to the page.
The page contains help, instructions, or app context that remains useful after login.
Turn it off when:
The page is only for guests before login.
The page is only a public landing page.
Signed-in users should start on a dashboard, list, queue, or workspace screen instead.
This separation keeps guest onboarding clear without cluttering the logged-in app.
Step 12: Publish and test
After the page looks correct, publish the app.
Test these paths:
Open the app while signed out.
Open the Content screen directly, if it is public.
Click every link on the page.
Confirm guest-only links do not send users to private screens.
Sign in and confirm the signed-in landing page is correct.
Check whether the Content screen should or should not appear in signed-in navigation.
Test on desktop and mobile.
For public intake flows, test the full path:
Guest opens the public Content screen.
Guest clicks the intake or start link.
Guest opens the public Form screen.
Guest submits the form.
The new Notion record appears where expected.
Complete Builder Options Reference
Content screens do not use the Content / Behaviour / Appearance tabs that data screens use. All options live in the Content page configuration panel. Each option below uses the What it does / How to use it / Why + recommended default pattern.
Visual editor
Editor toolbar
What it does: Formats text and inserts structure (headings, lists, links, images) without writing HTML.
How to use it: Start every Content page here. Add a heading, one short paragraph, and one clear next-action link before you refine styling.
Why / recommended default: Use the visual editor unless you need a layout the toolbar cannot express. Jumping to HTML first makes later edits harder for other makers.
Link control
What it does:
Inserts a hyperlink to another app screen, a public form URL, or an external https:// site.
How to use it:
Prefer full published app URLs or external https:// links. After publish, test every link signed out and signed in.
Why / recommended default: Links are the main job of most Content pages. Broken or private targets are the most common guest-flow failure.
Image control
What it does: Inserts an image from a public URL into the page body.
How to use it:
Use public https:// image hosts. Keep hero images short on mobile so the primary CTA stays above the fold.
Why / recommended default: Optional. Add an image only when it clarifies the next action or brand; decorative images slow the page without helping orientation.
HTML mode
Edit HTML / HTML source
What it does: Switches the page body to raw HTML for custom layout (sections, button-style links, grids). Unsafe tags and scripts are stripped.
How to use it:
Use when the visual editor cannot produce the layout. Stay under ~100,000 characters. Never rely on <script>, iframes, or inline event handlers — they are removed.
Why / recommended default: Off / visual mode for most pages. HTML is for branded landing layouts, not for embedding third-party apps.
CSS (optional)
CSS field
What it does: Applies page-scoped CSS for buttons, spacing, typography, and simple responsive layout. Limit is ~50,000 characters.
How to use it:
Put styles in the CSS field (not inside a <style> tag in HTML). Scope selectors to your page content; do not try to restyle the app shell or login screen.
Why / recommended default: Empty until the visual layout is correct. Add CSS only for brand polish that HTML structure alone cannot achieve.
Public access (private apps)
Public access
What it does: Lets anyone with the app link open this Content screen without signing in. Other screens stay private unless also marked public.
How to use it: Enable for welcome, help, or intake landing pages that guests must see. Pair with public Create Forms when guests should submit data.
Why / recommended default: Off unless guests need this page. Turning it on without planning guest navigation creates confusing menus.
Show in navigation for guests
What it does: When public access is on, controls whether guests see this screen in the hamburger menu or bottom tray.
How to use it: On for a public home/welcome page. Off when the page should only open from a direct link or button.
Why / recommended default: On for the primary public entry page; off for one-time or deep-link-only pages.
Show in navigation when signed in
What it does: Controls whether signed-in users still see this screen in navigation after login.
How to use it: On for help/instructions that remain useful after login. Off for guest-only landing pages so staff land on lists, queues, or dashboards instead.
Why / recommended default: Off for guest welcome pages; on for enduring help content.
Preview
Live preview
What it does: Renders the page inside the builder shell so you can check layout, links, and images before publish.
How to use it: After every HTML/CSS change, confirm headings, CTA visibility, and mobile readability in preview.
Why / recommended default: Always review preview before publish — source that looks fine can still feel cramped in the app shell.
Recommended page patterns
Public welcome page
Use this pattern when you want a private app to have a public front door.
Recommended setup:
Content screen: public access on.
Guest navigation: on if this is the public home page.
Signed-in navigation: off if users should go to a dashboard after login.
Add one clear link to a public Form screen or the login flow.
Help or instructions page
Use this pattern when users need guidance after they are inside the app.
Recommended setup:
Public access: off unless guests also need it.
Guest navigation: off unless public access is on.
Signed-in navigation: on.
Include short sections, screenshots, and links to relevant screens.
Public intake start page
Use this pattern when guests should submit a request without seeing the rest of the app.
Recommended setup:
Content screen: public access on.
Intake Form screen: public access on.
Guest navigation: usually off for the form and on for the welcome page.
Signed-in navigation: usually off for the public welcome page.
Test the form link while signed out.
Internal process page
Use this pattern when staff need a reference page inside a private app.
Recommended setup:
Public access: off.
Signed-in navigation: on.
Use headings for each process.
Link to the relevant list, queue, form, or details screens.
What Content screens do not do
Content screens do not replace database-backed screens.
They do not:
Display a live list of Notion records.
Create a Notion record by themselves.
Update a Notion record by themselves.
Apply database filters like a List screen.
Replace a Details screen.
Run custom JavaScript.
Embed unsafe third-party scripts.
Bypass private app access rules.
If a user needs to interact with Notion data, link the Content screen to the appropriate Form, List, Details, or Update screen.
Troubleshooting
I do not see the Content page option
Make sure the app builder version you are using includes the Content screen release. Refresh the builder and check the Add Screen picker again.
My Content screen is not visible to guests
Check these settings:
The app is private.
The Content screen has Public access turned on.
If guests should find it in the menu, Show in navigation for guests is turned on.
If guests should reach it by link only, use the direct published app link to the screen.
Guests can open the Content screen but cannot open the form link
The target Form screen also needs to be public if guests should submit it without signing in.
My signed-in users land on a different screen
Signed-in users land on the first appropriate visible screen in navigation. If a public Content screen is only for guests, turn off Show in navigation when signed in so signed-in users start on the right app screen.
My HTML changed after saving
Unsafe HTML is removed for security. Scripts, iframes, event handlers, and unsafe URLs are not allowed inside Content screens.
My CSS is not applying
Check that the CSS is in the CSS field, not inside a <style> tag in the HTML. Also check that the CSS is valid and within the character limit.
My image does not load
Use a public https:// image URL. If the image is private, expired, or blocked by the image host, it may not render in the published app.
Best practices
Give the screen a short, clear name.
Start with the visual editor unless you need HTML.
Keep the first screen section focused on the next action.
Use public access only for screens guests should actually see.
Keep guest navigation simple.
Hide guest-only landing pages from signed-in navigation when they are no longer useful after login.
Test all links while signed out and signed in.
Use Content screens to explain the app, then send users to database-backed screens for real work.
Quick checklist
Before publishing, confirm:
The Content screen has a clear purpose.
The page title and first paragraph explain what users should do.
The correct access setting is selected.
Guest navigation is intentional.
Signed-in navigation is intentional.
All links work.
All images load.
The page is readable on mobile.
The target screens linked from the page have the correct access settings.
The app is published and tested as both guest and signed-in user.
Updates in the 9 Aug 2026 release
Content screens work especially well as public Welcome pages in mixed public/private portals.
Pair with Show in navigation for guests / Show in navigation when signed in so Welcome stays guest-friendly.
Full walkthrough: Build a Mixed Public–Private Portal.
Release notes: 9 Aug 2026 Release.