Quite a few questions require output to be "truthy or falsey". This is possibly confusing as these terms can possibly mean different things to different people, and especially in different languages. How should answers interpret the meaning of these terms?

I'll provide a few possible answers to this - upvote or downvote according to which you think makes most sense. Or add your own answers.

  • \$\begingroup\$ Shouldn't the answer be "How the answer defines truthy or falsey"? \$\endgroup\$ Commented Feb 22, 2017 at 7:45
  • \$\begingroup\$ Possible duplicate of The Tag Categorization Project \$\endgroup\$ Commented Feb 22, 2017 at 7:46
  • \$\begingroup\$ I strong agree the way C language define Boolean: It is True one integer different from 0 It is False: 0 integer value. Boolean bool etc not has to exist for C and C++ languages. For the other languages the return type must to be Boolean (if it exist). If it not exist can be all: As [] for true and [1] for false (but it has to be one return value and not one exception or run time end) \$\endgroup\$
    – user58988
    Commented Nov 21, 2017 at 10:18

9 Answers 9


Consider the following pseudocode:

if (x) {
    print "x is truthy";
else {
    print "x is falsy";

If it results in a runtime or a compile-time error then x is neither truthy nor falsy.

  • 12
    \$\begingroup\$ I think that's a good definition. Almost any language should have some form of conditional, and the truthi-/falsiness of any value should be determined by which branch of the conditional it leads to. \$\endgroup\$ Commented Sep 16, 2014 at 7:07
  • 6
    \$\begingroup\$ The only problem could be with assembly languages which have jump-if-zero and jump-if-not-zero, but those special cases can be handled as and when the need arises. \$\endgroup\$ Commented Sep 16, 2014 at 8:10
  • 1
    \$\begingroup\$ Well it might get difficult with some esoteric languages like ///, where you basically need to build the conditional yourself. But I agree, the number of cases should be small enough to handle this on a case-by-case basis. \$\endgroup\$ Commented Sep 16, 2014 at 8:40
  • 2
    \$\begingroup\$ Another example is dc which only has call-on-various-condition operations and no well-defined concept of boolean. \$\endgroup\$ Commented Sep 16, 2014 at 16:45
  • 3
    \$\begingroup\$ Another downside is that I would consider "FALSE" to be falsey wheras this answer would consider it true in several languages. \$\endgroup\$ Commented Oct 4, 2014 at 0:45
  • 5
    \$\begingroup\$ @MooingDuck, no-one who wants to win a code-golf would use something as long as "FALSE" if they could use 0 or "" instead, so I think that concern is of negligible practical importance. \$\endgroup\$ Commented Oct 5, 2014 at 21:39
  • 5
    \$\begingroup\$ @PeterTaylor what about "0"? Also, 0 is truthy in Ruby yet I believe it should be allowed as a falsy output in code golf. \$\endgroup\$ Commented Dec 13, 2014 at 7:37
  • 2
    \$\begingroup\$ A more important distinction - one that this answer doesn't touch - are truthy/falsy outputs of the whole program. Is False falsy (as a stringification of False) or truthy (as a stringification of "False")? \$\endgroup\$ Commented Dec 13, 2014 at 7:40
  • 9
    \$\begingroup\$ @JanDvorak I think the point of this definition is that it is language specific, so 0 and "0" are truthy in Ruby, but falsy in PHP. As for printing to STDOUT, that's a good point, but I'd say the for simplicity it depends on what you are actually stringifying. \$\endgroup\$ Commented Dec 13, 2014 at 9:22
  • 1
    \$\begingroup\$ What if it stays unevaluated? Null seems quite falsy in Mathematica, but If[Null, "foo", "bar"] returns If[Null, "foo", "bar"]. \$\endgroup\$ Commented Oct 25, 2015 at 14:36
  • 2
    \$\begingroup\$ This makes any string truthy (or a compilation error in case of std::string) in languages such as C/C++; empty strings included. \$\endgroup\$ Commented Jan 20, 2016 at 7:42
  • \$\begingroup\$ Even shorter option: use double negation to determine truthiness. E.g. !!NaN gives false in JavaScript. \$\endgroup\$ Commented Jul 9, 2016 at 9:40
  • \$\begingroup\$ @user2428118: that doesn't work, e.g. in Perl it's possible to construct an object that gives any desired output when double-negated (via use of overloads). if doesn't have that problem. \$\endgroup\$
    – user62131
    Commented Dec 13, 2016 at 1:13
  • \$\begingroup\$ @MartinEnder: One of these cases ("some esoteric languages") actually came up recently; I answered a truthy/falsey question in 7, which doesn't have anything really resembling a normal if statement. The answer can luckily be easily changed to use any value for truthy and any value for falsey, but it's hard to know exactly what counts as valid there. \$\endgroup\$
    – user62131
    Commented Mar 21, 2017 at 12:32
  • 2
    \$\begingroup\$ What about cases like Julia, where 0 == false (and 1 == true), but if (0) is a compile-time TypeError due to strict type requirements? A strict reading of this answer would say 0 and 1 are then neither truthy nor falsey, but does that match your intention here? \$\endgroup\$
    – Sundar R
    Commented Jul 3, 2018 at 20:01

Truthy/Falsey should be taken as strictly defined in the given language. For example, in javascript, the following are always falsey:

  • undefined
  • null
  • NaN
  • 0
  • ""
  • false

And other values are always truthy.

  • \$\begingroup\$ I'll have to go with this one. If the question specifically asks for truthy/falsy values, this should be the default. \$\endgroup\$
    – Dennis
    Commented Sep 16, 2014 at 0:37
  • 24
    \$\begingroup\$ But some languages don't define truthy/falsey. e.g. x86 assembly (as I know). \$\endgroup\$
    – jimmy23013
    Commented Sep 16, 2014 at 0:45
  • \$\begingroup\$ Does javascript consider "FALSE" to be falsey? \$\endgroup\$ Commented Oct 4, 2014 at 0:47
  • \$\begingroup\$ @MooingDuck Not "FALSE", but false: console.log((0==1)==false) \$\endgroup\$ Commented Oct 4, 2014 at 16:26
  • 4
    \$\begingroup\$ and document.all in browser... (but who wanna such a long word in code golf \$\endgroup\$
    – tsh
    Commented Apr 16, 2017 at 9:08

Some languages have ambiguity in what is considered truthy/falsey. For example in c, zero vs non-zero is always FALSE vs TRUE from the point of view of conditional operators. But many standard APIs, for example return -1 for FAILURE and >=0 for SUCCESS. So answers may choose (and explicitly state) whatever sets of values they like to represent truthy vs falsey, so long as those sets are mutually exclusive.

  • 2
    \$\begingroup\$ While I'll like every OP to opt for this approach, I don't think we should make it the default. Just look at the return values of Ilmari's and my answer to “Convenient palindrome” checker. It's hard to draw a line with this approach... \$\endgroup\$
    – Dennis
    Commented Sep 16, 2014 at 0:39
  • \$\begingroup\$ @Dennis If the OP didn't ask for true / false values, but truthy / falsey, you could simply call every convenient palindrome truthy. \$\endgroup\$
    – jimmy23013
    Commented Sep 16, 2014 at 1:23
  • 7
    \$\begingroup\$ +1 Truthy (US, colloquial): Only superficially true; that which is asserted or felt instinctively to be true, with no recourse to facts. If you want true or 1, ask for true or 1. If you ask for "truthy", I'll give you something truthy. \$\endgroup\$
    – Geobits
    Commented Sep 16, 2014 at 2:14
  • 1
    \$\begingroup\$ I would consider "-1 for FAILURE and >=0 for SUCCESS" to represent an error/result union rather than a boolean, and ergo not a truthy/falsey thing. I could be convinced otherwise though. \$\endgroup\$ Commented Oct 4, 2014 at 0:47
  • \$\begingroup\$ @MooingDuck Consider also what UNIX shells typically do true; echo $?; false; echo $? TRUE == 0 and FALSE == 1 \$\endgroup\$ Commented Oct 4, 2014 at 16:23

Don't forget program exit codes!

If my C or C++ or perl or bash or ... program calls exit(0) this action could be considered truthy, and calling exit with a nonzero value could be considered falsey.

  • \$\begingroup\$ Exit 0 means "EXIT_SUCCESS" or something as that string; exit with not zero is indefinite (possibly there is another string one use for failure example"EXIT_FAIL" ... It is convenient make 0, all ok; number != 0 for error code (because fail can be for many reason and the success case has need only one value). But this has nothing in common with true or false values \$\endgroup\$
    – user58988
    Commented Nov 30, 2016 at 15:08
  • 1
    \$\begingroup\$ @RosLuP They are used as truthy or falsy in shells like Bash. \$\endgroup\$
    – jimmy23013
    Commented Dec 1, 2016 at 13:33
  • 2
    \$\begingroup\$ @RosLuP: EXIT_SUCCESS is 0 on basically every OS (because 0 has to work as success). EXIT_FAILURE is a specific value on each OS, but the actual value varies by OS (1 is common, though). Each OS also has its own rules for what counts as truthy and what counts as falsey on exit codes (e.g. UNIX considers all nonzero codes falsey; I've heard rumours VMS uses odd versus even). \$\endgroup\$
    – user62131
    Commented Jan 2, 2017 at 5:16

I would partition values into the categories truthy, falsy, and indeterminate according to the following rules:

The following values are considered falsy:

  • the zero value of the type of the result, if any
  • a NULL pointer
  • an array, the product of its dimensions being zero
  • a number whose absolute difference to 0 is not larger than 2-44.
  • a string literal parsed as a number yielding such a number
  • a string literal which when executed as a program of the language the submission is written in yields a falsy value. This rule cannot be applied more than once transitively.
  • an empty string
  • the boolean value false (if any)
  • a string which, when converted to lower case, is equal to one of false, no, f, or n.
  • a function which for any combination of arguments returns a falsy value. This rule cannot be applied more than once transitively.
  • of an enumeration type whose values are not associated with numbers the first enumeration value
  • of an enumeration type whose values are associated with numbers an enumeration value associated with a falsy value, otherwise the first enumeration value
  • a compound type (e.g. a struct) comprising only falsy values
  • a union type the last write to which wrote a falsy value
  • a pointer to a falsy value

The following values are considered indeterminate:

  • a NaN
  • a stray pointer
  • a trap representation
  • an undefined value
  • a function which for some combination of arguments returns a falsy value and for others returns a non-falsy value.
  • the absence of value, i.e. returning nothing
  • the absence of ordinary termination, e.g. termination with an exception or crash or no termination
  • a value, reading from which causes an exception, non-termination, or crash

All other values are considered truthy.


I think Truthy/Falsey instead of being language specific is problem (answer) specific. So in a language we can define different truthy/falsey s based on different conditions. For example one can define truthy as 53 and other things regarded as falsey and in the other problem truthy may be defined as an empty list and anything else may be defined as falsey.

In the other word:
An entity (and all other things that are implicitly convertible to value of that entity) can be regarded as truthy and anything else can be regarded as falsey or vice versa. The entity that is regarded as truthy(or falsey) must has only one exactly defined representation.

For example in Octave language one can regard true as truthy and anything other as falsey. Because all numbers other than 0 are implicitly convertible to true those can be regarded as truthy and 0 can be regarded as falsey. Also arrays that contain 0 such as [7 1 0] are implicitly convertible to false and other arrays are convertible to true.

As an example one can define an empty list {} as falsey and all other things as truthy because an empty list has exactly one representation. Also a list of {1,2,33} can be regarded as truthy/falsey and all other things can be regarded as falsey/truthy since {1,2,33} has an exactly one representation. But consider a function that sometimes returns a list and sometimes returns a scalar, so one can't regard a list as truthy because a list doesn't have exactly one representation so {1,2,3} and {1,2} are both lists but have different representations.

Also one can't define all even numbers as true and all odds as false except in those languages that evens are implicitly convertible to true.

Some examples:

| Truthy         |  Falsey        |
| 243            | anything else  |
| NaN            | anything else  |
| anything else  | 127            |
| []             | anything else  |
| anything else  | {7,2}          |
| "foo"          | anything else  |
| True           | False          |
| False          | True           |
  • \$\begingroup\$ I think that is a more general definition. Downvoters please add your comments. \$\endgroup\$
    – rahnema1
    Commented Feb 26, 2017 at 4:26
  • 2
    \$\begingroup\$ I didn't downvote, and actually I think this is good answer. Some languages doesn't even have an internal definition of type. But, I still have one objection. \$\endgroup\$
    – user72349
    Commented Nov 20, 2017 at 17:19
  • \$\begingroup\$ @ThePirateBay Good point! answer updated :) \$\endgroup\$
    – rahnema1
    Commented Nov 20, 2017 at 17:28
  • \$\begingroup\$ Some serious issue on "quine compare" question though \$\endgroup\$
    – l4m2
    Commented Jun 5, 2021 at 13:38

Answers should be able to specify what is truthy and what is falsy

Almost all of the answers here are either ambiguous or put some languages at a disadvantage.

For the top rated answer, there are many languages that don't have conditionals: Bitwise Cyclic Tag, any Turing Machine, etcetera.

For the answers that give values beforehand for what is truthy and what is falsy, what about languages with booleans such as fact or lie and win or lose? You can always fix these exceptions, but there will be more as the development of esolangs (or some practical languages too) will arise to new names for boolean/truthy and falsy values.

This is why I say that the answerer should specify what counts as a truthy value and what counts as a falsy value. This is to prevent an answer wasting too many bytes just because their truthy/falsy value wasn't on the list.

  • 4
    \$\begingroup\$ What keeps me from saying truthy values are exactly the values that let me solve this challenge with the identity function? \$\endgroup\$
    – lirtosiast
    Commented Jun 16, 2019 at 8:13
  • 1
    \$\begingroup\$ @lirtosiast Good question. A possible solution to it would be making it so that there can only be one truthy value and all other values are falsy. What do you think of this? \$\endgroup\$
    – MilkyWay90
    Commented Jun 16, 2019 at 14:56
  • \$\begingroup\$ That's incompatible with common ideas about truthy/falsy values in most languages i.e. Python, C, JS. I don't see an advantage of this over the modern standard of "any two distinct consistent values". \$\endgroup\$
    – lirtosiast
    Commented Jun 17, 2019 at 7:56

For a different view: Output and implementation are something different. A truthy/falsy value is an output that everybody with basic knowledge of common languages recognizes as truthy/falsy, regardless whether that is evaluated to true/false inside a programming language. It will be one of the following:


  1. The string True in any capitalization
  2. The string 1
  3. A floating point string representation of 1.0e0 -/+ eps(1)
  4. In case of functions: a boolean true. integer 1 or float 1.0e0 -/+ eps(1).


  1. The string False in any capitalization
  2. The string 0
  3. A floating point string representation of 0 -/+ eps(0).
  4. In case of functions: a boolean false, integer 0 or float 1.0e0 -/+ eps(1).

Both outputs may have leading or trailing spaces and newlines. Iff your language doesn't support any of the above, you should attempt to find the closest alternative. In all cases, all truthy and falsy outputs should be the exact same for your program, regardless of input.

I believe that in practice, these options will be accepted by all programmers to mean truthy or falsy, and eliminate loopholes. For example, cat could be a prime testing program if you define the set of all prime numbers as 'thruthy'.

Besides, if I ask you 'Are there any German spies around here', I want you to reply 'nein', not nine. In other words, a positive integer is not an answer to a true/false question. Neither is returning a set of all German spies, and claiming it's false if the set is empty.

  • \$\begingroup\$ The point of this answer is that implementation and output are separate things. Feel free to downvote but do it because you do not agree to that principle, not because something might be different in certain languages - it will only be time before somebody creates an esoteric language where int 1==false \$\endgroup\$
    – Sanchises
    Commented Sep 28, 2015 at 19:59
  • \$\begingroup\$ @nimi Incorporated your critique, thanks. \$\endgroup\$
    – Sanchises
    Commented Sep 28, 2015 at 21:06
  • \$\begingroup\$ Good edit, now your point is much clearer. However, I'm still not convinced that this is a good idea. The list of possibilities seems rather arbitrary. Languages have an advantage if they can directly print one of those values (print (1==2)) and a disadvantage otherwise. Lisp, for example, would be unlucky as it's native Falsey is printed as nil. -- Furthermore, some challanges allow the result to be returned by a function. In such cases we don't have any output at all. \$\endgroup\$
    – nimi
    Commented Sep 28, 2015 at 21:29
  • \$\begingroup\$ @nimi Sorry, I have never programmed in Lisp. For functions, see point 4 combined with Iff your language doesn't support any of the above, you should attempt to find the closest alternative. I prefer to use a simple set of rules with a catch-all clause rather than a extensive list that should be updated with every new esolang around here. \$\endgroup\$
    – Sanchises
    Commented Sep 29, 2015 at 9:40
  • 2
    \$\begingroup\$ -1 My main critique is that I don't agree that output is more important than implementation. If you are writing a function that should return a truthy value, you almost always want it to be something that is considered truthy by the language you're working in. Regardless of what an esolang's definition of truthy is, the output should still work within that language. \$\endgroup\$
    – Geobits
    Commented Sep 29, 2015 at 15:28
  • \$\begingroup\$ @sanchises: the iff-clause does not apply, because Lisp (to keep the example) is capable of outputting string literals like True. According to your rules alternatives are only allowed if the language cannot produce the specified outputs. -- Function return values: I read the rule as follows: Lisp is allowed to return nil (unprinted), but if it has to print it it must turn it into False/0/etc. That seems odd. \$\endgroup\$
    – nimi
    Commented Sep 29, 2015 at 16:45

This truthy vs falsey concept is way too ambiguous. Questions should be required to state exactly which values represent TRUE and which represent FALSE.

  • 24
    \$\begingroup\$ This is the only option I truly dislike. If my languages truthy values aren't the same as the OP's it puts me at a disadvantage. \$\endgroup\$
    – Dennis
    Commented Sep 16, 2014 at 0:31
  • 13
    \$\begingroup\$ @Dennis Agreed - if I could downvote my own answer, I would ;-) \$\endgroup\$ Commented Sep 16, 2014 at 0:33
  • \$\begingroup\$ *sees a score of -15* Coincidence? \$\endgroup\$
    – SE is dead
    Commented Jun 4, 2016 at 20:45
  • \$\begingroup\$ You can save bytes if return 1 insted of true \$\endgroup\$ Commented Jul 31, 2017 at 14:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .