Settings and view rules

Settings and view rules

Custom Views has global settings and per-view settings. Global settings decide where the plugin renders. Per-view settings decide which files match and what HTML, CSS, and JavaScript they use.

Global settings

Open Settings → Custom Views.

Setting	What it does	Recommended default
Work in live preview	Render custom views while editing in live preview.	Enable if you want designed views while editing.
Editable content in live preview	Keep the rendered view editable where possible.	Enable if you edit through custom views.
Work in canvas	Render custom views inside Canvas cards.	Treat as experimental.
Allow JavaScript execution	Run each view's JavaScript field and inline scripts.	Enable only for templates you trust.

Reading mode is the safest baseline. Live preview is smoother for day-to-day use, but templates with heavy JavaScript can still affect responsiveness.

Per-view settings

Each view can define:

Setting	What it does
Name	A label shown in settings.
Rules	Conditions that decide whether a note uses the view.
HTML template	The markup rendered for matching notes.
CSS	Scoped styles for the rendered view.
JavaScript	Optional dynamic behavior. Requires global JavaScript execution to be enabled.
Show properties in editing view	Keeps Obsidian's properties UI visible while editing.
Show inline title in editing view	Keeps Obsidian's inline title visible while editing.

How matching works

Custom Views checks your configured views in order and uses the first view whose rules match the active file.

Use this ordering strategy:

1. Put narrow, specific views first.
2. Put broad fallback views last.
3. Avoid two views with identical rule sets unless only one is enabled.

Common rule fields

Rules can use built-in file fields and any frontmatter property.

Field	Example value	Notes
file.name	Love and Machines.md	Full filename.
file.basename	Love and Machines	Filename without extension.
file.path	Music/Love and Machines/Love and Machines.md	Full vault path.
file.folder	Music/Love and Machines	Folder path.
file tags	music	Tags in the note and properties.
categories	[[Albums]]	Any frontmatter property can be used.
type	movie	Plain custom property.

Common operators

The exact operators shown in settings depend on the field type, but the common patterns are:

Operator	Use it for
contains	A string contains text, or a list contains one value.
contains any of	A list contains at least one of several values.
does not contain	Excluding strings or list items.
is / is not	Exact values.
starts with / ends with	File paths, names, and text categories.
is empty / is not empty	Optional properties.
before, after, on	Date values.
<, <=, >, >=	Number values.

Example: Movies rule

The saved Movies view in data.json uses an OR group: match notes categorized as Movies, or notes tagged with #movies.

{
  "type": "group",
  "operator": "OR",
  "conditions": [
    {
      "type": "filter",
      "field": "categories",
      "operator": "contains any of",
      "value": "[[Movies]]"
    },
    {
      "type": "filter",
      "field": "file tags",
      "operator": "contains",
      "value": "movies"
    }
  ]
}

Example: Albums rule

The saved Albums view uses a simple category rule.

{
  "type": "group",
  "operator": "AND",
  "conditions": [
    {
      "type": "filter",
      "field": "categories",
      "operator": "contains",
      "value": "[[Albums]]"
    }
  ]
}

Good rule habits

• Prefer stable properties such as categories, type, or a folder path over fragile title matching.
• Keep view rules simple and do advanced related-file logic inside a Bases query.
• If a note unexpectedly uses the wrong view, move the intended view above broader views.

Wiki pages

• Home
• Quick start
• Settings and view rules
• Template syntax
• Template logic
• Filters and functions
• Bases in Custom Views
• CSS and JavaScript
• Movie view tutorial
• Album view tutorial
• Troubleshooting