In form-style URL query parsing, a plus sign can represent a space. A literal plus inside a credential may therefore need percent-encoding when a URL is constructed. Separate username and password fields avoid some manual URL-encoding mistakes, but the service’s supported login format still determines the correct input.
Preserve the original credential
A password containing + should not be rewritten as a space in a dedicated password field. Encoding belongs to the process of placing a value inside a URL, not to changing the password itself. Use the supplied complete playlist URL when one is available.
Avoid hand-built query strings
A proper URL-building tool can encode parameter values without confusing data with separators. Public online encoders are inappropriate for live credentials because they receive the secret. If you are unsure, ask support for a ready-to-paste account link.
Recognize double encoding
A value already containing an encoded sequence can be encoded again accidentally. The resulting request no longer carries the intended original value. Keep an untouched source copy instead of repeatedly replacing percent signs by hand.
A practical sequence
- Enter the original password in a dedicated password field.
- Prefer a supplied complete URL over manual construction.
- Keep credential encoding work local and private.
An example
A literal + in a synthetic password such as demo+only is data. In a manually constructed query, %2B can represent that plus; changing the password to demo only is a different action.
Questions about this topic
Is %2B the same text as a plus in every field?
No. A dedicated password field normally expects the original character.
Should I decode every percent sequence?
No. Preserve the supplied URL unless there is a confirmed construction error.
