I've tried to import an option value via update_options($name, $value) where $value has special characters (like apostrophe's for example) and I've noticed that the apostrophe gets stripped out of the text before it reaches the database.

What is the suggested sanitization of strings prior to sending them to update_options()?

  • It should work with apostrophes just fine. This seems like a configuration issue or bug introduced by something, rather than native behavior. Note that inline documentation states that update_option() explicitly expects input to not be SQL-escaped.
    – Rarst
    Jul 13, 2011 at 18:49
  • could you please include specific example? It's waste of time to guess. :)
    – Rarst
    Jul 13, 2011 at 20:50

3 Answers 3


Try esc_html( $string ) (Codex ref), which among other things encodes single- and double-quotes.

For further reference, see the Data Validation entry in the Codex.


You should not use esc functions for data that's going into the database. esc functions are for output only.

The update_option() function sanitizes for you, so there's no need to run any extra san functions.

  • 2
    You're correct about esc functions being for display. However, as @ARWVISIONS mentioned in his answer, while update_option() does run sanitize_option(), if you follow through and review sanitize_option() you'll find that it only sanitizes specifically pre-determined options. Anything not in that list passes through unsanitized.
    – butlerblog
    Nov 22, 2018 at 13:16
  • @butlerblog No, that's not correct. If you see the update_option function code, around at line 412, you'll see this $value = sanitize_option( $option, $value ); without any conditions, so, update_option sanitizes everything; maybe it's serialization that got you confused because it doesn't serialize everything just non-scaler values. The $value parameter also has a comment "Expected to not be SQL-escaped". Mar 27, 2022 at 10:07
  • @Christos You're assuming sanitize_option() sanitizes every option sent to it, but it does not (and it explicitly states this in the docs). Please reread my comment above carefully: sanitize_option() "only sanitizes specifically pre-determined options." It uses a switch with no default, so anything not in the list is returned unsanitized unless you specifically set up a filter for that value. If you have something custom or otherwise not in the list, you cannot assume that it is sanitized, which is part of what led to the WordPress AMP exploit noted in @ARWVISIONS answer.
    – butlerblog
    Mar 29, 2022 at 15:53

I can't comment on Chris Flannagans answers so... update_options() does not sanitize all options. Some core options are sanitized, but custom option are not. You must sanitize the input yourself.


  • update_option() does sanitize all options. If you use update_option(), the very first thing that it does is sanitize the $value. See developer.wordpress.org/reference/functions/update_option
    – butlerblog
    Nov 20, 2018 at 21:00
  • they how come i can insert full calls to scripts and complete HTML tags using update_option?
    Nov 21, 2018 at 23:11
  • 1
    developer.wordpress.org/reference/functions/sanitize_option Not all options are sanitized by sanitize_option()
    Nov 21, 2018 at 23:13
  • Good point! Looks like sanitize_option() just handles what's pre-determined. That's definitely something that should be noted in your answer. You should edit your answer to emphasize this (as not everyone reads comments). It does provide a filter at the end, so sanitize_option_{$option} could be set up for any of those, but it's probably easier to just sanitize before sending it to update_option().
    – butlerblog
    Nov 22, 2018 at 13:17
  • It does sanitize everything and the parameter $value also has a comment "Expected to not be SQL-escaped". Mar 27, 2022 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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