At the end of the day, sprites and textures are just images - blocks of raster colour data (although sometimes we push the bounds a bit to put non-image data into them). The distinction is largely in how we use them.
We usually call an image (or a part of an image that contains many separate pieces) a "sprite" if its intended rendering purpose is to be drawn straight to the 2D grid of the screen, without perspective distortion. So what you see in the running game is basically what you see in the image file itself (apart from colour tinting/palette swapping/transparency effects). This applies to the background tiles and characters / interactive objects in 2D games, "billboard" cards like particles and older styles of tree & shrub rendering, and also to the user interface elements and icons in 3D games too.
Conversely, if we're using an image to provide surface detail for the polygons of a 3D object that might be drawn in perspective, we usually call that image a "texture." That name has carried over to other uses of image data to modulate rendering of something else, even if they're no longer about texture in the sense you could feel with your fingertips - things like reflections, distortion maps, overlays, masks, or any general-purpose use of images we don't feel like naming more specifically tends to get lumped under "texture" in our loose nomenclature.
That makes the bounds between the two fuzzy and not particularly strict. If I have an image containing a sequence of fire and smoke plumes to use in drawing billboarded particles for an explosion effect, I might call that a "spritesheet" or a "flipbook texture" interchangeably. Or if I have a tileset image comprising all the background tiles for a 2D game, I might call that a "texture atlas" today, by analogy with atlas textures developed for 3D games, even though its data and use in my 2D game is indistinguishable from what someone else would call a spritesheet. If I have a rectangle of geometry whose purpose is to present a single image to the screen, I might call that a "textured quad" or a "sprite" depending on what I want to emphasize about its use.
(Note here in this last example that "sprite" stands for both the source image segment in our game assets, and the instance of a rendered game entity that uses this image segment - another way we use this terminology a bit inconsistently)
You'll find some engines and libraries encode this distinction in rendering intent into their own nomenclature. For instance, in Unity, you can choose to import an image asset as a "Sprite" - this enables an extra set of options that are commonly desired for UI images or 2D game assets, like spritesheet slicing & packing, and the ability to reference parts of the image as discrete entities in your scene and object setup. In these cases "Sprite" often means "an image (texture) plus metadata" - but it's still rendered the same as ordinary textures under the hood. The extra packaging is a convenience so we don't need to micromanage UV offsets and the like everywhere we want to use the image; instead these frameworks conceptually pack that data in as part of the asset entity itself.