Scriban for .NET: a templating language you can also use as a scripting engine

The problem Scriban solves for .NET teams

Most .NET applications that need to produce text from data start with string concatenation or string.Format and then regret it. The next step is usually a template engine, and the choice is between one that embeds C# (Razor) and one that does not. Scriban sits in the second group. The README describes it as a scripting language and engine for .NET, primarily developed for text templating, with a compatibility mode for parsing liquid templates. That sentence covers the two audiences. The first is a team that has templates written by people who are not C# developers, or templates that arrive from outside the application entirely. The second is a team that wants a small language to evaluate user-supplied expressions, for example a calculator or a rules layer, without handing over the full .NET type system. Scriban is at the core of the scripting engine for kalk, a command line calculator, and the README gives that as an example of the general scripting use. The common thread is that the template author and the application author are different people, and the application author needs to decide what the template is allowed to touch.

How Scriban parses and renders: AST, visitor, and the sandbox

The pipeline is a lexer and parser producing a full abstract syntax tree, then a runtime that walks it. The README states the parser is not regex based, and that source locations (path, column, line) are kept for error reporting. Two consequences follow from that design. First, the AST is exposed: there is a ScriptVisitor, parent links on ScriptNode, and Template.ToText, which writes an AST back to a textual script. The README describes this as useful for roundtrip script update scenarios, and it is also the mechanism behind converting a liquid template to scriban syntax: parse with Template.ParseLiquid, then call Template.ToText. Second, because the runtime walks a tree rather than executing compiled C#, the set of reachable objects is something the host controls. The README calls this an extensible sandbox execution model and says you have full control over which scripting objects, and therefore which properties and methods, are accessible from templates. That is the part that matters if a template comes from a user. The default convention exposes .NET members with lowercase and underscore names, so MyMethodIsNice becomes my_method_is_nice, a choice the README attributes to matching liquid behaviour. A MemberRenamer delegate changes it. This default is worth checking early, because it silently reshapes every name a template author will type.

Installing Scriban and rendering a first template

Scriban ships as a NuGet package. The README gives a single command, and the package targets netstandard2.0 and net8.0, which the README says covers .NET 6+, .NET Framework 4.7.2+, and other compatible runtimes. A signed variant, Scriban.Signed, is published separately.

dotnet add package Scriban

After the package is restored, parsing and rendering take two calls. The README shows this exact example: parse a template string, then render it with an anonymous object. Note the capitalisation. The template writes {{name}} and the object property is Name, because of the lowercase convention described above.

var template = Template.Parse("Hello {{name}}!");
var result = template.Render(new { Name = "World" }); // => "Hello World!"

The rendered string is "Hello World!". If you already have Liquid templates, the same shape works with a different parse method, and the README gives the Liquid version of the identical example.

var template = Template.ParseLiquid("Hello {{name}}!");
var result = template.Render(new { Name = "World" }); // => "Hello World!"

For a loop with a pipe, the README uses a product listing. The pipe calls a built-in function, string.truncate, on a member.

var template = Template.Parse(@"
<ul id='products'>
  {{ for product in products }}
    <li>
      <h2>{{ product.name }}</h2>
           Price: {{ product.price }}
           {{ product.description | string.truncate 15 }}
    </li>
  {{ end }}
</ul>
");
var result = template.Render(new { Products = this.ProductList });

The output is the HTML list with each description cut to 15 characters. Async rendering uses Template.RenderAsync, and the README lists it alongside the synchronous call.

Where Scriban is the wrong tool

The Liquid mode is the first place to be careful. The README states plainly that the liquid language is not strictly defined, that there are various versions of liquid syntax, and that there are restrictions while using liquid templates with Scriban. The linked document is called liquid support in Scriban. A team migrating a large body of Shopify-flavoured templates should read that page before assuming a drop-in swap, because the compatibility mode exists to ease migration, not to guarantee it. The second boundary is Razor-shaped work. Scriban is a separate language. If your views need to call into C# services, run LINQ, or use the type system directly, you are writing a template in a language that deliberately does not have those things, and the sandbox that makes Scriban safe for untrusted input is the same mechanism that makes it awkward for trusted, C#-heavy views. The third is the naming convention. Because members are exposed as lowercase with underscores by default, an existing template corpus written against PascalCase property names will not render as expected until you either rename the members or set a MemberRenamer. That is a migration cost, not a bug, but it is easy to underestimate.

Scriban compared with Fluid and Razor

Fluid is the other well-known .NET Liquid engine, and the difference is one of scope. Fluid's reason to exist is Liquid: it implements the language for .NET applications that want Liquid semantics. Scriban's Liquid mode is a compatibility path on top of a language that is not Liquid. The README says the liquid language is less powerful than scriban, and that the mode allows migration from liquid to scriban, with Template.ToText converting a parsed Liquid template into scriban syntax. So if your requirement is Liquid and only Liquid, Fluid is the narrower fit; if you want Liquid as an entry point and a richer language underneath, Scriban's design points that way. Razor is a different comparison entirely. Razor compiles templates into C# and gives the template author the full language and the full type system. Scriban interprets an AST and gives the host control over what is reachable. Choose Razor when the template author is a C# developer working inside your application. Choose Scriban when the template author is not, or when the template itself is data you did not write. Scriban also positions itself as a general scripting engine, which Razor was never meant to be.

Licence, releases, and what maintenance costs look like

The repository is licensed under BSD-2-Clause, which is a permissive licence: it allows use in closed-source products provided the copyright notice and licence text are retained. That is a statement about the licence text, not legal advice, and a team with specific obligations should read license.txt in the repository. The repository is not archived, and the last push was on 2026-09-21. Three releases land close together: 7.5.0 on 2026-09-21, 7.4.0 on 2026-09-05, and 7.3.0 on 2026-09-04. That cadence tells you the project is moving, and it also tells you the upgrade cost is real. A minor version bump in a template engine can change how a template parses or how a built-in function behaves, and the README does not document a rollback procedure for a rendering regression. The practical mitigation is a test suite that renders your real templates and compares the output, run before you take a new package version. The README also notes the package includes source embedding, though the supplied text is truncated at that point, so check the package contents if embedding the sources into your assembly is part of your plan.

Editorial conclusion

Adopt Scriban when you render text from data you do not fully control, or when you want a small embeddable scripting layer inside a .NET application, because the sandbox model and the ScriptObject-based AOT surface are the parts that carry the design. Do not adopt it as a Razor replacement for HTML views with heavy C# logic, and do not expect the Liquid mode to accept every Liquid dialect, since the project documents restrictions. Before committing, read the liquid support page, check the MemberRenamer behaviour against your existing property names, and confirm the target framework in the NuGet package matches your runtime.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. README
4. Releases
5. scriban/scriban on GitHub