How to define a character string in SAS using quotes

In SAS, a character string is created by surrounding text with quotes. Single or double quotes work, with double quotes allowing variable resolution inside the string. Omitting quotes treats the text as code or names, and the $ sign marks a character variable type, not the string itself. So, use quotes to define strings.

Strings, quotes, and a bit of SAS magic

Let’s talk about one of those tiny, everyday SAS details that can trip you up if you’re not paying attention. How do you denote a character string in SAS? It sounds simple, but the way you handle quotes matters—especially when you start mixing in macros or trying to keep your code readable.

The baseline idea: strings live inside quotes

In SAS, a character string is just a bit of text you want to treat as data, not as code or a variable name. The most straightforward way to mark that text is to wrap it in quotes. Think of it like writing a label for a piece of data so SAS doesn’t mistake it for something to execute or a name to reference.

Two flavors that both work

• Single quotes: 'Hello World'

• Double quotes: "Hello World"

Why the two options exist is kind of convenient. If your string contains a lot of apostrophes, you can switch to double quotes to avoid escaping them. And conversely, if you’re crafting a literal string and want to avoid any macro vibe sneaking in, single quotes do the job just fine.

A subtle but important distinction with double quotes

Here’s where things get a tad more nuanced. Double-quoted strings can participate in macro variable resolution. In plain terms: if you have a macro variable, say, %let name = Jamie; and you write a string like "Hello, &name", SAS will substitute Jamie into that string. It’s a handy trick when you’re stitching together dynamic text for reports or logs. If you’re not using macro variables inside the string, then both quotes behave essentially the same for the purpose of denoting a literal string.

On the other hand, single-quoted strings tend to stay literal. Within a single-quoted string, common macro variable resolution doesn’t happen the same way in all contexts. If you’re writing code that must remain unwaveringly literal—no surprise substitutions—single quotes are a safe bet.

Words you’ll want to keep in mind

• Quotes are essential: without them, SAS will interpret the line as code, a variable name, or a function name. That means you’ll see errors or, worse, unexpected behavior.

• The $ sign isn’t for quotes. In SAS, that symbol is a telltale for a character variable type. It doesn’t create a string literal by itself. You’d see something like $name to declare that a variable is character, not to trap a text string in quotes.

• A string can hold punctuation, spaces, or even line breaks if you handle the syntax with care. The moment you wrap the text in quotes, SAS knows you mean a discrete piece of data, not a command.

A quick example to ground the idea

Suppose you’re assigning a value to a variable in a data step:

data example;

length greeting $20;

greeting = 'Hello World';

show = "Hello, &name";

run;

In this snippet:

• greeting uses single quotes to store a literal phrase.

• show uses double quotes, which opens the door to variable or macro substitutions if present.

• length greeting $20; is how you tell SAS that greeting is a character variable with a maximum length of 20.

A moment for context: why this matters in the real world

Strings aren’t just about neat labels. They’re the backbone of reports, user-facing messages, data cleaning notes, and even error handling. You’ll string together file paths, formats, and descriptive texts. You might build dynamic strings for log messages or for composing the content of a generated report. The minimal, reliable way to denote a string is through those quotes—single for literal stability, double when you’re ready to lean on macro-variables or want the nudges of substitution.

A few practical habits to keep your code clean

• Be consistent with your quoting style within a block. If you start with single quotes, keep that approach unless you intentionally need a substitution.

• When in doubt, lean toward single quotes for literal strings and reserve double quotes for moments when you explicitly want macro resolution.

• If your string contains an apostrophe, consider using double quotes to avoid escaping, or vice versa. Little tricks like this keep the code readable and save you from needless backslashes.

• Remember the $ sign is about data types, not string delimitation. If you’re assigning a character variable, you’re labeling a type, not enshrining a string literal.

A tiny tangent you might enjoy

Many folks who work with SAS end up juggling text that originates outside SAS—CSV files, for example. If you’re pulling a field that could contain quotes, you might preprocess it or choose your quoting strategy in SAS to preserve the content intact. It’s a tiny dance between data ingestion and data presentation. And yes, your choice of quotes can influence how cleanly you export text back out to reports or other systems.

Common pitfalls (so you can sidestep them)

• Forgetting the quotes: writing Hello World without quotes will lead SAS to look for a variable or function named Hello, then interpret World as extraneous.

• Mixing quotes inconsistently across a long piece of code: you might end up chasing a string’s end with mismatched quotes, which is a classic source of syntax errors.

• Overusing the $ sign as if it creates a string: that symbol signals a character variable, not a literal string. Treat it as a type hint, not a way to define a literal.

A warm, practical takeaway

In the everyday rhythm of SAS, the simplest rule still holds up: denote a character string by surrounding it with quotes. Single quotes give you a solid, literal text bubble; double quotes offer a doorway to dynamic content when macro variables or similar substitutions are in play. And the $ sign quietly reminds you of a character variable type, not the character string itself.

If you’re building a workflow that includes messages, labels, or descriptions inside your SAS programs, you’ll likely lean on both kinds of quotes at different moments. The key is to stay mindful of when you want literal text versus when you want that little bit of substitution magic. That awareness makes your code not only work, but read well—like a good note left for the next person who wanders into your project.

A final thought

Strings are one of those unspectacular tools that quietly shape the experience of your data work. They’re small details, but they have a big impact on readability, portability, and maintainability. So the next time you write a line that includes text, pause for a moment and ask: should this be a literal string, or do I want a little substitution to happen behind the scenes? With single and double quotes at your side, you’ve got a straightforward answer—and you’ll likely end up with code that’s a touch more elegant, too.