I am learning programming and often see the term "string literal" being used in various places. From the looks of it, it seems to be a synonym for "hard-coded string", but on another hand the term looks quite specific.

Is "string literal" always the same as "hard-coded string"?

  • 6
    Have you read the Wikipedia article on string literals, or done any other basic searching? If so, what have you read and what, exactly is confusing?
    – Thomas Owens
    Commented Dec 9, 2015 at 15:46
  • Thanks @ThomasOwens, I read that article and I think my confusion came from that in another article someone was writing that it was not the same as a hard-coded string (but I have since then lost the URL to this other article). It could be the article I read was specific to some programming language but I wanted to clear up this confusion of mine. Commented Dec 9, 2015 at 16:22
  • I guess somewhat related: stackoverflow.com/questions/25746/… and stackoverflow.com/questions/3911452/…
    – user165549
    Commented Dec 9, 2015 at 16:29
  • 4
    The difference between the two terms is semantic. "Hard-coded" frequently carries a negative connotation, implying that the literal string should actually be retrieved from configuration, etc. A line of code like connectionString = "blahblah" could definitely be called hard-coded; a line like inchesPerFoot = 12 might not.
    – BJ Myers
    Commented Dec 9, 2015 at 18:20

6 Answers 6


For me, a string literal is a language construct, an hardcoded string is a string whose value is fixed in a program (you may discuss if it needs to be fixed at compile time or could be somewhat determined by some runtime consideration). An hardcoded string is often a string literal but could come from other sources (say concatenation of character literals or even some fixed computation like concatenation of a product name with a product version when the version is stored in a pair of constant integer variables).

  • Thanks @AProgrammer, but what does your statement "a string literal is a language construct" mean in this context? Commented Dec 9, 2015 at 18:12
  • 1
    Corroborating with Robbie's answer, I wouldn't say that last one is a hardcoded string. The source variables may have hardcoded initializers and the string computation could be optimized at compile time, but the string itself is built from other sources and the computation does not need to be modified to change the string value, only the source constants.
    – JAB
    Commented Dec 9, 2015 at 18:19
  • I wouldn't say that concatenation of variables (even if constants) is hardcoded, but maybe ['a', 'b', 'c'] or String.fromCodepoints(97, 98, 99) are examples for hardcoded strings that don't use a string literal.
    – Bergi
    Commented Dec 9, 2015 at 19:15
  • @JAB, I'd not be surprised if there was variation about the precise meaning, even from one person. I tend to use hardcoded as soon as I don't have convenient way to modify it without modifying the program, even if it is determined at run-time (say it use the installation path of the executable) but I'd nor argue that a definition which require that the string be determined at compilation time. I'd tend to think a definition which won't include the concatenation of a string and a preprocessor macro overly restrictive. Commented Dec 9, 2015 at 20:01
  • 1
    @SherlockEinstein, take the reference manual for your favourite language, I expect to see the syntax of a string literal described in it (some may call it string constant but others prefer to use string constant for named constant object with a string type; I've never seen the word "literal" used for anything but a kind of token) Commented Dec 9, 2015 at 20:04

It depends.

Here, a string literal is used which is also a hard coded string.


But here, a string literal is used to define the constant (which is also a hard coded string). However, the print statement no longer uses a hard coded string since it depends on the value of the constant.

const name = 'Robbie';

Yes, the terms do mean the same.

A string literal means the way a string appears in the code (say in JavaScript, that would be quoted in either single or double quotes ('literal' or "literal"), in the same way that you would have numbers appearing in code - again, a literal (so, in the code var n = 2;, the 2 is a numeric literal).

As you can see - this is the essentially the same as hard coding strings/numbers.

There are subtle differences, but for all practical uses - they are the same thing.

  • 4
    I believe there is sometimes a subtle difference...
    – Robbie Dee
    Commented Dec 9, 2015 at 16:45
  • Excluding such things as string interning (which I would not ascribe to "hard-coded strings"), the two terms are essentially the same. Commented Dec 9, 2015 at 16:56
  • 2
    I would not use one term over the other, and expect somebody to realize the difference between the term I chose to use and the one I didn't use, so I agree they are "essentially the same," especially for communication. Pedantically, they might not be exactly the same, but you're wasting "thinking bandwidth" by being that pedantic. Commented Dec 9, 2015 at 18:15
  • 3
    Meh. A string is "hardcoded" when its value can be determined at code-compilation time rather than at runtime; string "literals" are a syntax for specifying strings, usually consisting of an opening character, a closing character, and an escape character, with most other characters allowed to literally appear between these. For example, the Haskell string reverse "Hello." can be hardcoded in that form even though it is not specified by the string literal ".olleH"; the PHP string literal "What $_GET[sorcery] is this?" is clearly a string literal but the variable is not hardcoded.
    – CR Drost
    Commented Dec 9, 2015 at 18:44

A string literal is a hard-coded string, but not all hard-coded strings are string literals.

var greet = ", ".join("Hello", "Bob")

The above code has three hard-coded string literals: the comma, Hello and Bob. The variable greet is hard-coded to be "Hello, Bob", but it is not itself a string literal. An interpreted language would never in memory have those characters stored as "Hello, Bob" prior to execution. A compiled language could, if it were clever enough.

The connotation is that hard-coded means "doesn't change with input", and is generally a stepping-stone to modifying something like the above to this:

var greet = separator.join(greeting, name);

In many cases, some things may still be hard-coded, for instance:

var greet = ", ".join(greeting, name);

Although the comma is hard-coded, one would not normally call that fact out unless there were a need for a different separator.

  • 1
    I'd rather add, hard coded means, can't be given as input and can't be configured, but that is of course a blurry line. Is configuration input? Is modifying a string literal in a script source configuring it, especially if there is a section with values you are meant to edit to configure things?
    – hyde
    Commented Dec 9, 2015 at 20:03
  • If there is a configuration file with a hard-coded string, and the configuration file is taken as input to the code, then the value is hard-coded in the configuration file, and not hard-coded in the code. The code is still flexible then, and doesn't need to be modified to modify the value of the string. That input is applied by the compiler, interpreter, etc., but it's still input.
    – jimm101
    Commented Dec 9, 2015 at 20:16
  • ... In fact, the point of the configuration file is that the code isn't hard-coded.
    – jimm101
    Commented Dec 9, 2015 at 21:07

"String literal" is just a construct of the programming language that you are using. In C or C++

char* p = "This" " is " "a string" " made from four string literals";

is a single hardcoded string made from four string literals. Swift on the other hand has string literals that are not hardcoded strings, like

let aString = "i + j = \(i + j)"

The term string literal refers to how your language's parser interprets your program. After the preprocessor (if any) is applied to your source code, tokens that look like "Hello world" will typically be interpreted as a string literals by the parser.

The term hardcoded string refers to a string that doesn't depend on the input to the program but it also has connotations of being hard to change, meaning that you might have to edit the code in one or more places to change it.

Here is a string that is both a string literal and it is hard-coded:

char * libPath = "/usr/lib";

Here is a string that is still a string literal, but its definition comes from a preprocessor macro:

#define LIB_PATH "/usr/lib"
char * libPath = LIB_PATH;

It's still a string literal, but I'm not sure if I would call it hard-coded. The definition might depend on some #ifdefs, or the definition might be generated by your software's configuration scripts, which inspect your computing environment and configure the software to work properly on it. If "/usr/lib" doesn't actually appear in your source code but it comes from your build system, I think most programmers would not call that "hard-coded", because hard-coded has connotations that it is difficult or not supported to change the variable.

Not the answer you're looking for? Browse other questions tagged or ask your own question.